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Abstract 



A system for performing intelligent analysis, segmentation and partition of a database based upon attributes 
associated with the data in the database are provided. A report may be generated which allows a user to make 
decisions, without requiring the user to understand or interpret data itself. A database computer includes a database 
containing the data. The data includes a collection of information about an enterprise of the user. A server computer 
is coupled to the database computer and executes a database management program. A client computer is coupled 
to the server and executes an application program. The application program allows a user to define predetermined 
data types, to define relationships between the data types, to define parameters for the report, to define a method of 
analysis for the report, and to create the report. The report summarizes the data in terms of the data types, the data 

IB 

relationships and the method of analysis. I 
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ect) (ODBC) >fy^-7x-XW-htl) 

• a>tTjL— ^3 2^:f-^^ • n>-ejL— ^34 

^^s^afiaoDBc^gi-r^^w^Lv^^ m 

[0042] id-CH2«r#H8-r6fc. 9v4TVY • 
t^yXfA 1 2^-if^^XxA l o SrfilflW&T 
r'J^-yay- rn^7AtJ>0, Windows 
NT T m ifctiW indows 95™ <9:*^U— T" 



*-^5<K :7*/l^^^7£/;^A5 4. 

5 6. ^^fA5 3!rg^tl> I n f o F r am e 
t m iii^MDTT K i-X h U-^ffl>( y^»7x- 
X5 7£S-tf* 

[00431 o/^y • *>\x— ;U50«i?5-f Ti'h 
■Ht^X^Al 2tf>lO<03tT— /i«t**3VtA — ^ 
3 0±T8iUV^*»k'a^f x y ; L, 3>tr^ 

y - ^S/jl— 0HJ:^TJfti?iii»JL-if^^^)i«— 
[0044 ] 
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V—^rA • yXrA(DOS T!1 
NT™. Windows 9 5 




7-4 Is? • ^XrA (DOS™ 
NT . Windows 9 5 '7«tc) 




d7 ^-f T > h/-tf-— A • tyj. — -Jl' 
bT 








i 

Me t a d a t a TM ©AP I 6 0 t'fctb 
T 




> • ^-zl— 5 1 CWLT 




MDT7 H5ZXh U— ? Rl< >^ — ~7 
x — X 5 7 I^LT 



[0 04 5] jl— iW^-X-rA ■ TH5-7M/-n' 
7yXfA 5 3—55 fcHflHWfeilT V*S4 



InfoFrames^M ^it/x-yxyh 

t^fA12^^-h777^, fcitWUSR 
^Wt^ $lL<5Sj£Lrt: I nfoFrameTM^ 
nDA I *jr?isX7-J* 1 4*^^|BI-&*>**«yi"f 

a*:. 7*;^«a^^ ; f^5 4«4a:^fc^(c 
[0047] . (VHifML nm. *»sas> 

• I nf oFr ame™ (tTjL— . fflftk. 77T- 
K r»jyb [ I nf oFrame™Ot'x-- 4 
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#7 i my *)vy - *7it* ? J: ^xm 

nfoFrame™^'JXh, &it/X— V hCO 

[0048] irr£/^-T-A55BI4*rLV«|^fBO^ 

a T M CQAP I 6 O'v&^ix. *L"C*«oa. jl- ir<o 
Metadata™25 £3HW-&fctf>fc:D A I V7 
ls*^J*\**<&t>tth. 1T7 r v'^A5 5A(i^.-if 

liMetadata™ <7)A P I 6 O^iH^iX, *<0 
*^)JL— 1ftf)M etadata™25 £®&rr§ 

*^^BI^^*M***4T3 

*LT^^«^Bfcm-&*n«iORI»tS 

r«Hnrt-*j . 4fc*i r|B«Eeo»©IBWdattft»tfe 
ftTV^iij cO^T'&^o 4*:. 2o<03BOffi3iBiao 

*^^Bfcll*4>*lfctt»ktf>B8«3&< I n f o F r 
ame sT m 0+ttt3fcftC3 Vt*-^3 2it« 

[0050)rt'JX h^HlfT'^XxA 5 6 141*^0 
XlrisjL-jl'ZixfzUtf-hlZttLXY?- h ZJZm 

[00 5 1] -KlWfc 

t. 



^\ I n f oF r ame™ . XycOT^yxhOUtT) 
[0052] -b^ V hit«T^ U X MltfOTi-lfiH 

- rt'jxb* 

--iWB&IB. 

• — JXHr ^ V h . it®*:?* y h 

• ^Tya^h'J* * -CO-h (77-h • 

>\ I nf oFrameTM % JSlJOT^U * hOl£fT) 
[0053] »©IB»«r*y XMiXWi-1f»i 

■ -J«W©HB. JtKSO^B 

• ^yiss ycoxirisx.— )V 

• *7 is 3 yco h >J # 

I nf oFrameTM ^\\cr>Ti~V Xhcnmff) 
[0054] %mftffi T + U * h «i»^JL-1fWtRlS£ 

• 7t'JX^ 

• — iX-fe^jx y h . ffitfwr*' a y<7)-fe^> v h 

• &*3tHfa. JbHBHIB 

- ^r>-3 ycvhVtf -^f^h (77-h ■ > ^-fe- 

>-\ InfoFrame^M ji^rt'JXh^) 
[0055] M-yH^Srr-t-'JXh^cOJL-ifStR 

• 7t'JXb« 

. Mia. ^sspg 

• *7>-3 XOhVtf • (77-h • *<y-te— 
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>\ InfoFrameTM^^fijxhtOUtT) 
[0 0 5 6] ^-m±T+VAbjmzmf£tz&m$f 

^(D^^yv^m^thiio^mm^ti, tan,* 9 

ir><7)^7*>VtzW*mfc'?hZttfX'* . *LT* 

y x h *^*rv jl-ju-tz tzMzmm-tz a t #x* 

ZkifiTZt. x^i^-/P£;h/O^V*T^yxM2 



[0057] jL-i«i«wr+y x h *flB&r*fc»fc 
y x h taw * h y - 1 #v 

hy^'ftfts&^^LfciWiWfc:. T^-hifclil n f 
oFramesTMJIf. T^'J X h^ft^^X^ 
A 5 6 tt7 * Z^flt/yXfA 5 4 t£» LX ^ 

[00 58] 



Save 


3.— if«>8K$n^7^-y x Mc*tUTigism/x^>— 


Save As 


SIR $ 7 ± "J X b K*t L T3L- tf #jB«J&:/t 5 * - 


S u bm i t 




i 


■^^^ y h^fcifct;;? a-ZI^WH^S/X^A 5 4 



[0059] *3t. r^yxh^^y^x^ii^ 5. 

^Metadata 1 M C7)AP I 6 QlZttLXfi [00 60] 
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Get al 1 Measures 


T^O&Wtf&ZtztflZ* Metad 
a t a™ AP I 6 (MC&LTfr&tD 


Get all Concepts 


T-e<O^S^*Sfcr^t^, Metad 
a t a™ AP 1 6 0 V^Z/T^tI* \Z 


Get a Concept's Partitions 

A— 7^ 5^3 >£f#£>) 




Get Partitions 
rt-^J is 3 




Get Segients 

i 





[0061] InfoFrame™ tfjL— -f >^ • If 
r^fA5 3(iWYS IWYG^^f^*^. *il 
(i InfoFrame™ 5 3^ InfoFrame 

SJWSfifcl nfoFrameTM^ 
®M(C^^i"-S) . jl— if^^^co InfoFrame 
™KH'J^- ^^*£fc£i^Lfc%&. In 
foFrame™ h'jL — f >^ ■ t/yXfA5 3ii 

[00623 JL—fifi InfoFrame™ ±x?7 

r menu i tern — V i ew (j< — jl— • 

isX^rM>5 4l±%(01 n f o F r ame T M &M.htiib 
£ InfoFrame™ b* jl— >f >^ - f/yXfA 
^jlfcTT & . .x— »f sWKfiECD InfoFrameTM^ 

•y^LfcB*. I n foFrame TM t* jl — f >^ • If 

SlfT/^X^^tcKLT* DA 1 1f:7VX^A 14 

[0063] I nf oFrame™ tTjL— >f >^ • If 
3fcfc> If****, Info 
FrameTM^-xLt, HTMLT*WlTV*ft 



HTML^ ^tiftUcT) F * * J* > h * fctt U V -XlcS* L 
T'J^Ui^R^yhM, 11136. 7*-V y 

1fl4^^fcftO^T^>flWBSrai*-r*. 

t^Tii. ^wvf y >?ti$r Lwr-J-y ^ hi* ±1/ 

I nfoFrame™ tijotJ:V\ 

[0064] InfoFrameTMfa — f >^ ■ If 
/yXfA5 3t:J:^T, JL-if^N e — »f(cJ;oTiR* 

^-^tZCOm^Ztltz I n f oFr am 

InfoFrameTM^UNI CODEi^iiASC 

I l3»Kf7)7t-77btHTML7r>f/^LTft 
^Ctit'l^, RffSftfcHTMLI nfoFr 
ame™ lie *-MZimLX X—Jl'T&V&'tZb 
ifiT^h. A-y' 3 y3. OcOHTMLT'^^if*. ifc 
(i-eilh^fffi=5:&mO7'^^1f^HTMLC0 I n f o F 

r ame™ £gRMfc*<TS6. 

[0065]Metadata™^API 601^7 
If /i/XfA 1 2 D A I *r7isXfJ± 1 4 

H^i*f-^, "f**>t>, MetadataTM2 
5. I nfoFrame™, a-f-rn7r>f;k 
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etadata™ <OfflfiC9*&£\ Metadata 
t m coap I 6 0iiMe tadataTM 2 5£ilfth 
Bfl^it^rra«lgSrS«-r^o InfoFram 
e^M^ MetadataTM£OAP160(il/ 

f -7n7r>f^^ Me tadata™OAP 
I 6 0ii^L-if^iijD. JL-if^!2SEi5j:^-if^0 

[0066)Metadat a<0AP I 6 OCCj: -oT, 



«fcifc»±BWrt"*C:i:3&«r**. Metadata 
[0067] 

1 
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Me t a d a t a ™£MSrr-5 


•V7~>Zt2* 55A/S5B/55C J 

/v \J 


k <T> ~Z ^ A? -7 

\s n vj j w S\ f*t 










7*;^fI-t)-y->XTA 5 4^?> 




MDT7 K ^ h U — ?m^ — 
~7 jl — 7 5 7 if* *c> 


X *r v a. — ; V £ M W ^ & 


7tUX h^Ulf 7x7rA 5 6^b 










^l— If 


MDT7h^-XM/-^ffl< y 9 — 
7x-X 5 7*6 


-7 ;£.gfll lt^-^~ 

— *- 5T ray tw* 9 •© 


Ayf T* ^7" ^ — ~7 K J , ffl Y "*>><7 

!7x— X 5 


■ 


MDT7 M/-^ffl<>?- 



[00683 Metadata™COAPI 6 0te#OT 

£<r"CH3Sr#§H*-*i:. DAlt/i/Xf^l4li'J 
^-y.X»J7-7^-y't7 0, InfoFrame 



t m -fe-^u— * 72. Metadata™ SsR^E^ a 
-H-7 4. Metadata^ UsK^MJ 7 6. fc<k 
tfMe tadata™ o— K*5 £tf3BK : e> ; .a.— ^7 

[0069] Metadata™ y ^^h'J 7 612^ 
— ^ - ^T^;*2 4cO^CDMe tadata™ 2 
5<7>3l3S£^tf. ^Metadata™ 2 5«ii^X 
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fAl OcOziTThZ. *il«^x7VN^;*2 4<0*O 
m^T-ftz^XcoXAf^J X^M%\i*~i:^ 
U LX I nfoFramesTM^{tg|;^i 
^tf*^7^yTJ>£. Metadata™ 
U7 6(i7 r -^ • ^xTvWX2 4<^+c0*g|W ; 5:Me 
tadata™ ^/iDSMt^fAl 6 £J: 
oTX^-hr^7-^^fi§iti», Metadata 
t M ^y^b y 7 604 J C<iTie^4a!)i^>S*W=5r 
Metadata™2 5tffoh. 
[0070] * Tav-trh (Concepts) j : 

a>*7h&T-?£%titz^xmfo&zttfxZh 

JftfcSL a-H»)x7) *^««$ix. #aO*S8ift# 

f^six*. x-iFjis? ^ytrh ^aafitrr £ - t 

(Tffi#S8) - ;ft«iMetadataTM 
U^> ? hU7 6604 3 ^Me t ad at a™ 2 50f< 

J>«-*fca6fci. BHfrojftft SQL) (rv 

[007 1] ■ r Wr—-9 (Indicator 

s> j : ^^^-^iJMRt-ri^-^oaiPSraffi 

• rr^-h ( A 1 e r t s ) j : 77-Mi:*IWi: 
a t a™ ff TtiSrV*. **lfe«M e t a d a t a 

™<o*frrr-Mi^^+TaffiS<is* Witf* x 

*£««t>3fc»g\ ^«J2rI n foFrameTM 

h y #<&fr£-rx / ^^^ss^fg^-r s <r t t-cs 

T?— hCO'J^MiDA If^fAl 4tCj:o 



UtT^iX*. CKDMe tadata™ 2 5I4D 

a i t^yxfA 1 4 in** lt tflflnrtfi-c* o . * l 

TInfoFrame™ fS^Mti^tttbtl 
*. 

[0072] • r gS£JggfI]?)KI& (Measure 
Relationshipslj : fl^lSia^nffiU 

*04S^«Jn S:»*"*"* J . d^gOM e t a d a t a 
™ 2 5ii I n f oF r ame™ (Zifti>*fcK— 

fc&v^ftboic. afcgjssra^ra 

«&^*fc*>fctt*rfl*. Metadata™ 2 5(4 

VKJC^S^tlS. Metadata™ 2 5<£>£j£<0 
rntxiiH7-il lcotpTXOmMlz^ZtiX^ 

Metadata™ 2 50!>4»t;:*4il* fcOii* 
iO^tCjiotS*) 1 ? (Metadata™ 2 5 

etadata™ 2 53&«ttt><l. ^<03W)±fflfS 
(7)Metadata T M2 5#£«$*L&^&tt#* 
0. -?-LT Metadata™ 2 5?:f-^ * ^xT 
J\^X 2 4 fcl^tLTV 7Ttl)^J) 47 7t^« 
fHd^ttStlS. -t^TCOMe tadata™ 25 
(4. v . y b* >7fgm$:&&>X . -~mcDffli&T-7Jl><7)tp 
IzmtiZtiZ. Ztit> (7)mf% : f-7MZ'r- 7 ■ ^xT 

[0073] Metadata™ 4 
tt^7-f7>h ■ t7'yXfAl 2X14DA If/y^ 
T-A 1 4C0l>-m^A i ^<^. Metadata™ 25 

Metadata™ 25^DA It^fAl 4*> 
4>5?^f&. InfoFrame™^l/-^72li 
x— ^Zlft^h InfoFrame™H yx^yy 
x-h-r^dkco— gBtLT. f^Vya/Wi^x 
y— Sr^-tSfcafctCMe tadata™ 25S:K^ 
f|,.Metadata™25 

[0 0 74] Metadata™M^ya- 
yP7 4ti^^>f TV h ■ t^y^fAl 2*>A>c7)Mc t 
ad a t a™ tf)M#rt>*!yi't& - x— fii^Or-^ 

&zt(,z£^x. mLi^7*yh£m.1}[rt&. zcoy" 
4 x sis b vii^co^xT^N^xco-f— 9<n*9M&<n 

T-?mmz£^xv#~h2ttKcittitf*^*i^ m 
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&oTfi§££*i*: r®&\yT??-j fcBfttti*«U* 

0. Zftb<vmL^7*>h£Ztlimz<01 n f oF 

if (C J: oT^S*l*:*g\ Metadata^ C7)n- 
KfcJ:tfM^^-;U7 8tcJ:oTx-* • ^xTa 

[0075] 1 r>ftV7'isXT2*timc0^7i<>XTJ±fr 



B C_I D : 



B C NAME : 



B C_DE S C : 



MAP P I NG ; 



[0077] j>isy--?mmmm±7 7<<T>h * -9- 

2 5t»UT»LvW>y>-^*3iJP'r-&3tift><OS* 



f^l2KDAI t/yXfA 1 4tcWLTi*^>iX 
tadataTM 2 5l=»LT*rLVV3V*:rh£iIiin 
[0076] 



[0078] 
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B I ID: 


C1CD< ^ vcr— ^Sr^L— — ^7 ("fmS'JTS I D 


OWN E R : 




B I NAME : 




B 1 _D ESC: 




MAPPING: 




ROLLUP_OP : 


u -)v t y * *?T-r s it & omw? 



[0079] i^i$<o7t-77 hir&crmox-h [ooso] 



B I ID: 




# najw-rs I D 




B I NAME : 








B I_DE S C : 








EXP ; 

1 









[0082] 



[0081] HJHHS«>f V j^-*5eS3S£tt? ^ -f r 
>h • t/S/^f Al 2KDAI1f7 , i/Wl 4(3 

tadata™ 2 5KSLT#rL^H£IIIfH^ 



(18) 
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CI ID: 


CKTjHmKflW £3---:* CBtgiJir* 
I D 


OWNER : 




C I NAME : 




C I_DESC : 




B I I D 1 : 




OP : 




B I I D 2 : 




RANGE : 


— i 



[0 0 83] x^-^mmtfyjyyh -*r-f*s%rt 

? >f ^co^tiD A I ^^^^A 1 4 



DAIt/yXfAl 4(CttLTj*£>il&* -fe^Vh 
BRS*BMetadata TM 2 5fc*TLT*rUHr" 

[0084 ] 
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1 

S E G_ I D : 


CCD-fe^^>h«r3.--^caS'J-r* I D 


OWN E R : 




S E G NAME : 




S E G D ESC : 




S E G L EVEL : 




B C ID: 




ATT R I D : 




OP : 




VALUE ; 


z<D-t#* > h Kit-rate 



I I I 



[0085] I nfoFrameTMf^^ry SrUU nfoFrame™ * • 



SE_I D : 


ZL<D 1 n f o F r ame T ^^-^|:^i|t^, 
I D 


OWNER : 


:©InfoFr ame T¥ $^Lfci-if 


S R NAME : 


COInf oFrame ™cDfc1tr 


S E D E S C : 


:<Z)I nf oFrame ™OS i5 


S R T Y P E : 


4*1580) InfoFr ame™</)^0^ 


B C_ I D : 


ZL<D I n f o F r ame TH t:W53>t7h 


S EG_I D : 


CCD I n f o F r ame™C)tift5>t^ > h 


TIME: 


CO I n f oF r am e ™l;:*rr*&*ffifl3fii 



[0087] f^^yg^^x'J-iiDA I if y x >f * >is 3 ^W^r^xU— iir— * • >>xr/^A2 
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$mth. D A I t/xXf^ 1 4Uf ^ Vi^ 3 y W 
^X'j-S-Me t adat a™ 0)*.?* > V^M± 
tzlZ^-r- yfem?) U JX K Metadata 

7frbLTDSMV7i'ATMZttLXMi£th. DS 
[0088] ^^-fT^h • tyyWl 2iiDAI 

MBKK* 

• I nf oFr ame™S* 

[0 0 89] DAIf/yXf^Mli^^-fTyh * 

• I nf oFrame™ 

[0090] DAI t/^fA 1 4{^y'a-7 * 

DA I t/i/XfA 1 4(i:D SMf/yXfA 1 6 
•Metadata™ 

[009 1] D S Mt/y Xf A 1 6 (i D A 1 1 y i/X 

• SSRSfLfcM etadataTM 

■ * - W7A^^fetf)f- ^ 

• SQLX 

• Metadata™ 



JX*-V 1 8l*DA I IT/v'XxA 1 4«C»LT<Koaj 

[0092] Metadata™ <0n- Kfc Xtrggj 
tya-^7 8liyXf^X^-h7 77^CMe t 
a d a t aT m tO'J^'h 'J-7 6if-^ • ^iTa 
^X2 4<^3^$iXT^&&^W&Me t ad a t 

etadata™ On- F*5 i^BR*^*-/^ 8 
4<7)*Nc§£Mt\ 

[00933 InfoFrame™W-^7 2li 
DAIf7yXfAl 40±gSfft£§|3S*$*£u Inf 
oFrame™ <0£»£*^V*4jl— iP<0T^>J X 

H»SS*l*. DAI^+CHSStltt^-fe'yhKI 

h ffl£/U-^S:a»?f & *>l=T ^ U ^ F O * 4 r **tt 
HU;U- bjL-yxf^ 7^iil/^- 

<y F • ^^vh^if^Wffi^Udf-hSii&^S**. 
fiil/^-fe^^h. W-^7h --fe 

f^x Ffffi&l'— . f^rx Fffrfri— ;Wi 

• V-^T *y7*SS ( HTML) OiSt^7^7yh 

• t/yxf^i 2t;:#LT>££*i&. ^:>fyx^ 

>is3L—hZtltz InfoFrame™ Z'foh* 
[0094] InfoFrame™^U»^72li 

• 77Xh7^ F - ^X'J-^f^^aW^x 

• f7^- A ( I nfoFrame 
ZftfR-tZtilbliZMe t adat a™ 2 5£&oJm 
•Metadata™ 2 5i:^x7Vv>;XA*feKS*L 

Metadata™ 2 5^i7A»)XK 
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[00 95] Mtil. \ nfoFrame^li 

h • byOO-h r|5ttffl^*yj ^ >f vis*— 9 r& 
Sj iSJiWBHI r i 994^1 2/?j ^fotf^y 

£r?x'J -tt-r- * *3 J: IX* * -v^t/yXfA 

QLfcSSftU *PR*3-t<ttlHTr*. «UifWS*i 
fcx-^SrDA I t/y^fA 1 41::** LTilU 

[00 96] m&T7Xh??h - ?i»J-t:liftttX 

^gam^thzkifirrv*. h - b^*x • 

4 VS^-* (SJI) ifif-y-y h • b^*x - nv-fe 

3a#*«£-*-6'T-f*>'>'3 >0 $:ItW£0Meta 

77C0WBoaS?{c*5V^TU!K— b • -t£*lx— 5>7 28: 
<?&tifi'J?%^ 7 1ST) • /7 7*« 

*O*JeLfcfc<0(c^7^4»"C r ^Ofi!i (Ot h e 
r ) j *W*Ttt$. 

[0097] • x»JT • 7 0*4?7 

-f TVh • t/yXfAl 2£*«-&E£8:1#oTl*S 
x-iflc4&it^&*§^:4oT. InfoFram 

xfA l 2BDAit/^f^l4fc:WJ^-y • 
x y T£>+fc:*^x-ip (c^-r^-r^T of- * 

014^-^- n>tr^-^3 2±c0-e^»J^-> - x'J 

ST'^^-fr^h • r?yb-jL-^3 0^jMOilf . 
[00 98] ^T*H4£#gg-r&h. DSMt/yX 
fAl 6(4SQLb*^U-^8 0*3i^Me t ad a t 
a T M ;i'J- ■ ^ya-;P8 2^T'V^ e SQL 
0i4D A I t/yXfA 1 4*»£>SfI£il 
^f^yyHy^X'J-?:, * • *>jiT>>v> 
X 2 4 Ztmtf& tzMz®,*>tl& S QLXC 



SQL^l/-^80liInfoFrame™5: 

^jSL-thm^fcotiMz. da i^y^^-rAi 4cc^ 

[0099]Metadata™ ?X»J- * b**L— 
* 8 214D A I t/xXfA 1 4 y h SilfcM 

etadata™ 2 5 {Zl^t hWSiOm^' h . isX 
f Ax<0X ^ — h T y D A I t/yXfA 1 4 J4ftJ 
^-XSrlOJDHW"Srt:tf>fc:* t^TOMe t a d a t 
a TM 2 5£g:£*r&. JL-if^g^Ob^> 
h^nfc^liSCMetadatai" m ;iy- 
••b'^l/-^8 2Wa^ DAIt/yXfAl 
4CcMetadata™ (DW$\WS$:&Xf2'&& . 
[0 100] Idt'15^#Itl)i:. X^>^-5 - 
f/^fAl 8(4T^-h^i:rXU7K-b<7)X^^ 

T v *4 X ^ it jl— /PS ixfc T-MI X h fcSSWWKxX b 

4tC^tT7 r ^X>'N- yf-r^ 0 X^^-^^^y 
h S fltrf^X (Offlft T~f° V X h £ D A I t/y^fA 

MMDT7 F $ - x h ^(Ci: ^TJfcfctCflt*^ 
X^t^jl— 7lifaA* 7 ft2 5 1 3 
tfO^ffitCioT. CD A I 1 4 BlC^rLTT-MIXh 
^ig-T (H34) . 

[0101] ££-CB6H21 9Sr#ffg*T^fc. ^7>f 
T^h • t/yXfA 1 2*$J:V^eO»f^*«i«BtSS 
ilTV^. ^7-<ryb-tyyXfA12{^7^7 
>h -t/yXfAi 23^jHtSix&i:Scash.*— »: 
^-a'-1/>( 9 8£-£tf. ^-A'^l/>f9 8(i3o<7)f 

>fxrM • xur i oo—i 0 4&&m<r>y*}i>y • 

^^VH^. • ^Xjl-1 0 6. ^4:1/^ 

>-i i o~i 2oco+^o. 7t;i//w>fyKW 

n^fc U^7^7yh- t7yXf A l 2^*l:i^ 

[0 10 2] fa/H • x»JTl oo\±y*foycr> 
U X b . **U4 InfoFrameTMii 

4 ix-eti ^ -s. r u x h sr«j«'r & kcc ^ 5 >r 

T>-h -If^^XT-Al 2tc4oTfi6i?ix-&^^7r — 

UXh^cog^c07*;W^(4^7>f T>-h ^ 
i/XfAl 2^H^T^fl^ h ^ (.Zfyar-jl/bX-fflfrtl 

[0 103] fU7M • XUT 1 0 2WaBRSil*: 
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yt^ycoWzfoh I nf oFr ame™OUXhSr 
#tf. InfoFrameTM|^»^« 
^il^A^^2 1(CJ:oTSI!RfC^'r^ ( I 
bifiV^h. WInfoFrame™ ££XT'^& 

Y)V • SgfiSfifc*fc^fc*>aflS*t"0>*# 

(change) j ^WttS64rf-*»«fO^-f Tfc LT 

3 6«4&*:{t;LT (HI 9fciR$*rO** 
-kite) *<rtm*tt<*Z-h* *MX*XS£t&Z 

1 3 6»i#^^l 2 2 (019) SraBR-T-Sii: 
Wot.MVOTindows 3. l™.Wi 
ndows 95™, & ±l/flS£>W i ndowsOift 
ffaW^O i-if o T S < ffl MrO * S *SCC J: o T 

[0 104] f^xrw • x'JT 1 0 4l*aSiS*ifc 

.XM4I nf oFrame™ h E &Wtz#>lZ 

3h.?&SWI*«3*. ;^8M2 1fcJ:oT*h*aSW- 

;^W^H^130 (B7Hail)#W7t'J 

fUf>fX7M • X'JT 1 0 2CO 
4H£U:*h§ixT^£*ttELTV*S I n f oF r a m e 

t m sr^fiEf s^fr-tt*>ix-& (farw - xyr 

1 0 2<7>"tHcy;*h$ilT^£ InfoFrame™ 

/IMWSCfclir#4K filliWindows3. 1 
™, Wi ndows 95™, *5 J: lXffi<7)W i nd 

[0105] (06) ttr;u^ 

y * ^-jl-i o 6 ^ort^co-^Mf^n v >- f £H£t 

il*. tf^l 1 OliT^'JXh • h*/P*W-f VK*> 
130 (17-il 1 ) iWVtot. X9>1 1 2\±m 
«-fe-y hT-y 7* • *}4-yY*7 1 3 2 (HI 2) 

xri/>f ■ xyr l oo~i 0 4<ort»<oHtRSiifc:7 



X'JTIO 2^^>StR?^ I n f oF r ame T M (C 
ioTM^^K^l 3 6 SrPHXaj-f. ^V122 

5 0i*7V>h • #^>"C*0. 5 lfcioT 

i-WaBSJBB ifc*^*, *LT*?^ 

1 5 2fcJ:oTJL-^agfflBH^)im(***4fctt 

[0 106] H7— HI 1 Sr#«M-*i:. Tt'J^b • 

UXheO^UiiT-MJ^h* (Analyst Nam 
r ftVr0)?4 7 (Ty p e of Analysi 

s) j 7-f-;PHco+Tatf*i&. -t^wssarrs 
^flfcfon&is^rasaa* 5 r ±^ffl^se ( p r i 

mary Measure) j 74 — )V K0>+TaffiS 

jtf^h (DefineSegments) <0'J^bA*£> 
a^SiX^o mmz. ^InfoFrame^CS 
"rSMBaJ^ r*fc§iiS?>f A • XyjX (Time 
SI iceConsidered) j7>( — )V HCO+T 
5£it£*t&. I nf oFrame™li r fip^pl^rK — h 
(Report Now)j i£f WmXRth Z t £ J: 

£^jl— Tt'JXh (Schedule Analy 
st) j tf^V^aiR-T&iIkCJ^T I nfoFra 
m e t m <7), N * . y f-cT)— LT ^ ^ ^ a— £ CI i: ^ 

[0 107] HI 2Sr#B8-r&fc. ««-fe*y hT*yT • 

(Description) j 7 -f — ;P HO+tCJBh. 
£o ^L-iftCckoT^^^SO l3&«iSttftSii/i«f. H 
1 3CD^V ^K^ 1 3 2 Jifrf ^>tt. JL-if3&«-fe^ 

[0108] Hi4^#ffg-f-^i:. mmcomjzmmzm 

fg-t "/hT'/T" *>-f ^F^l 3 2<7>«£JHB-r4A-f 

^JttS*«f** [m^mS* (Measure Na 
me) j 7-f-/PK<0+fc:3K*l£. 391^5 B<0£*4 
r ^i5 (Definition) — Ktf>**3!I 

i$X?&ZttfX'£&. HI 5ii>i:lXHl e^jH-TS 
*7<t VH^l 3 2l4tB©«B6a9?'r6fcft. i5J: 

r/H=^ >- b Sra«?"r&fca6(c*<i-rii**-r&c: t ^ 

[0 1 09] HI 7Sr#Ha-rSk. ^S^@ra^)RI«S: 
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%MBfficom&l} r I f -The n j X^MX^M^iX 

tfmizm&yj-U'Wtpx'MiRZix. zta* r i f- 

Thenjjonf j OSfcfr£:gUrr* BB«Wt4><X 
T^V^^Wl^FO+OSI^Sgtel f-Thenjt 
<0 TT h e n j OS#£^f£^&^£«^:7 4 

^-fy^l 3 2<O^Bfc:J:-3TiS(lia'r*Ci:3&«T* 

So 

[0110] InfoFrameTM tfV^y 
^O^^il^ecX^v^-^S^tT^^'^S. In 
f oF r ame*r m m^ya-'J^i^I^I n 
f oF r ame T M ^T^tC^T 
mX'$>h. InfoFrame™«WIH r ^ 
SPS (Time Interval) j 7>f-;l/F^ 

xmm-f&zttfx'Z, *tuma. mou* 

-b^H^gftt^o B19*#!lW-*i:. In 
f oF r ameT m ay— mfiMft *7 4 > V 1 3 60+ 
t£iS3*VO*&. 3gftSft*#WO*>f7tiI nf o'F 
rame™ W^iltfcl ^-f Wl^-^*— 
T* rSaMMfr (Change Analysis) jh 

^yF')i32^w>'b'f^AM ^o+t« m t 

56«§*I*:) «i r4«2U:CO*»S:IStt-rS ( S t o r 
e Ages Greater Than 3 Yea 
rs) jtM. (Wfg-b-y hr^r * ^ 

2 Ogling 7 * /nM ^0+TtJB9fc3E* 

*7>r * (rt'j^F * bvu^ • y^i 300 

[0111] InfoFrameTM{^i^j|@, 

r-^^K^i 3 2o«£3Bsiaowffi7*' , w m 
^■co«awrx^-h>>h^aft-r4. act. inf 

oFrame™ li3=gU5£jg @ ^ [SJ t JBSt<03E±«fc: 

I nf o F r am eT m {^«5@«J:ii)L 
TV^f^Xh - 7-^£*:te^7:7 4 • 7~'-7iz 

[0 1123 i^TEI2 0S:#ga , f 4k. 9?4T>Y 
* ^7>-.X7A 1 2 ^fotM etadata™ 25 



ir^JfrT**:*)*)^** r S8«i ( START ) j 1 4 0 

Xf771 4 2lc*$tvc % JL-ifii^^a^-ferKcJ* 
i-* lo4fc(«*iJ3Lh<oatt*Jg^rs. 
[0 113] ^T771 4 4i,Z^X. 9=7* 7>b • 

O'J^h^a-fCgfttl*, X77ri4 6t:i3^ 

7T4. ^L-if^^Onv-trrhiDil/JStt^o^TO 
7**hfcJ:*e»fc^i-*£fc^**. *7*y7 
14 813*5 WC. jl-1P«7— * * *>X7VW-*2 4<0 
rt^O7~^O+C0lOC7)*7A(C^LT locO^V 

[0114]Xf771 5 0(3&vvr. ?7-fT:xh ■ 
t^fAl 2ttB«fc*:'y*-*£v*7*SB 
«K0rt:tf>fc:. #5AOU;*h£^— IfteStt"*"*. *7 
7715 2t:fcv^, jr-ifd^ *y 75ii*: -fv>^— 

y*7Ali<XO*iM V y KSrlW— h-T*. 

•ana: 

• mmzx^tzmm 

[01151^7771 5 4l3*>Wt\ JL— WiH^B 
«03WtS-iffi*i"Sfci60»M (verb) . *<r)4 V 

-?<DT**hi,z±&mwzmm~t$>z£tfxzz>. * 

7-/71 5 6(3*5V^T. ^7>f7yh-t^7Al 
2(i>f yi/4r— ^o*7^*fili"rv^7— 7;PS:JKtt 
0*7A*ffliTv^6^-7;Ufc«-&S*6C:k3&«'r* 
4. 

[oi 16] v 7 1 ^7>fryh- 

^WAl 2C4J-— if* s 3aJnie7)3y-fe7hS:A*L 
fc V ^> fc* o ^ S- ¥»J5rf 4 . AlJt/cV ^^-(4^7 v 7 1 
4 2^M4. A^J Lfc< ^^1^777*1 6 0(c*3 

[0117]<2. ;7>f7yh-f7 r yX7A12> 

;7^ryb •t/xxf^i 2 a«jaTfcSfcfcRL< 

KqB$tL&. 02 l(4^^>f 7>h * t/yXfAl 2 
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^2a.-if ■ >fy^-7x^ (UI ) 1401. 
-y>1402, feiW-A'cOAPI 1403tft 

-XcOif^X^A 14 0 1 ^T^L-if l 4 0 5li 

?^r>h l 2t*tf^&^tan > §&* ciopsbo 

W</H;:;fcvvckL JL— if • >fy^-7x-X * *T7*s 
X^A 14 0 1 1402tAPI1403 
<nwn<^r—\L7. £f£ ? i t . v*-^> 1 4 

0 2 fct-^AP 1 14 0 3frhW-V**mmt 
t-A'OAP I f/yXf ^ 1 4 0 3lif^t^^ 
?4TVY\ 2**DA Itry^fAl 4 t?T9*tfS£ 

2 £■ D A I t/yXfA 1 4 <^fg<7)^T<^fflfI<2? 
^^ryh-t-A.tya-^MCSM) 14 04£ 

[0 118] 02 2i*02 l<oyov?BS:3£fc:3L 
< Lfcl^I/Ctf)* ?^>f T^h * i^f/X^l 2?) 
T'Oy^H&SLTV^. jl— if • A >? — 7x.—7. • 
t/yXfA 14 0 m^L-if 1 4 0 5icSLtltl» 

AtiS«<0MS-Wi ndows^>f/^ro/7A 
fcLTSI^S SOT. W>^-7x- 

xiiloco^-f > * ?5>x£j#t>. -tco^USrJaT^B 

[0 1 19] ^7>f7>h • if^^x^l 2£0+£03 

5 i i-c*&. v • ^-y 

i^x 9 h 1 5 1 1 tiM icrosoft Founda 
tion Class (MFC) 7^ 'J^)X^— h 
777- n-KfcJ^TaiSWfcfffeii*. 77*n- 



x <md i ) OTry^-i/s^+wu-^ • ^-f 

h. 

[0120] jl— if - y • ro-trxli 2oc7)Xt- 
AP I ^r^Xr-M, 14 0 o n n e c tHBM;:** 

■ if— A3 2frt>t&gifi&^ ;^7h7-; • 
[0121] o^>f ytz&Xcth t . >y4T 
xn7tmm.^tl. *LTi-if 1405«iS»cO*iM 

(^7-f7yM2t^<, t-A'3 2t:i;o 

j *>is*s:5bu ;^7yM 2«om 

£\ ^7^7>M2li r^-^ . 5>fyj FTirt> 
±3&«0. *n*Ci-?TJL-ifl405tt«ffSilfel n 

££jfc*Jfctt«frr *>Sl*«I nf oFram 

[0 122] iZWiizmhLtztZ . T~rv*—*say\± 
LfclS*. jl— if 1405*«7HS-Xhl/^ (MD 

ta> nnmz^zfrt'otiwm^tfmnLxMZ 

&£ltz&&. 77'Jt-yay- ^/xin 1 5 1 
[0 123] 
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Connect 



Disconnect 



Display Manager Window 



[0 124] rrn-^ay • ^/yx^M 5 11 
tic 1 nt_Ap P ^7^^^y^T'l)l> e Ztl 
l£c 1 n t_Us erLoginDl g&itfc 1 n t 
_Ma inFr am e^^il-^fUCO^T loeM >^ 

1 n t_App(iMFCcO 
^^CWi nAppW^W*!.. *mil±C 

nitlnstanc efiSfgfc^— A— HL. 

£\ S^>>f V- >-H^. c 1 nt_Mai nF 

[0 1 2 5] c 1 ntjla i n F r a m eliM F C<0 
;^CMD I F r ameWndW/;7Atfc§. 

1H8Bv*— ^-v • ^yh^yx^yxi 5 1 2£ 

£jfcthtzMZ. OnCreateSig^-A'-^ 
Ft~£o c 1 n t M a i nFrame-f 9 VXti 

20dt>^lo4fcii InfoFrame™ cot" jl— 
V • ^^K^l 5 17) tcJ:oTJ!UIS;h.&. c i n 
t_Ma i nFrame^ yxltb'CO^ -f > 

[0 12 6] JL-if • D^y^ro/ll MFC 
CO^^XCD i a 1 ogOW7Xtfc$c 1 n t_ 
UserLoginDl ^XC0>f VX^V^fclJ; o 
T#J&P£il&o c 1 n t_U serLoginDlgiO 
-f yx ? vxtt i-if fc* hu £ ' « V - H Sr & J: 



(if— /tO A P I VyzsXy-Jx 1 
4 0 3) 



iry ^3 > * ~?*V*> HAP I 
(if- ;t©A P I iJ-y^X^A 1 
4 0 3) 



y->^fA 1 4 0 1 J 



k. pfixajLTv^mia A Jgsn*. 

[0127]Toolbarll MFCOCToo 1 B 
arW^7^tfti^7Xc 1 nt_ToolBa 
rCO-f >-X^^tCj:^T»JfflI$ft^. lnt_Too 
1 BarliCToo 1 B a r ^<0^T<0fflgg£»fci; 

h£ilJirr&, CToo 1 BarC0>f y^^V^lilO 
^)7*^<?5KD7r (Trash^yol^) . 
lo*3t«*<TJ2LhcOT^yxh ( r>>ffi (Tras 
h)j. rip^{RunNow) j , 
( v i ew) j tf?>cr>±'W) % *>J:tXlo£*:te^ 

fLtLhcOI nfoFrame™ ( r (Tras 
h) s r^(view) , ^j:tf r/ijyh (Pri 
n t ) j vct)±^o) £§(tAix&. 
[0128] f##^l§ 1 5 1 5«i-b^>> h . 

fc^Lfc^T<Z»tfi**tr. fR«£«l 5 1 57o 

ix(i^m^fL^>ts?so*^>fr t rk(cio-ro$)^ 0 * 

C0^>f TD^iic lntMainFrametCioT^f 

[ 0 1 2 9 ] c 1 n t__B ui IdMeasureDl 

c 1 n t_B ui IdSegmentDlg. Z-<T>y 4 
Tuflz X oT^--if (lBHSTO-b^> >- h tJBRifctt 
Bfllft-rs**. *SV^iJBtt^«lRRSrffiitr*C:i:fc:J:o 
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c 1 n t_Bu i IdRelationDlg. iO?' 
>f 7D/C in ta-f IJSi^M e a s u r e R e 1 
at i o n£WSi£til±fflm-tZ,1>\ *>S^i*rLv*H 



[0 130] 



i 



GetMeasureRelat ionship 


Metadata™coAPI W— /tCDAPlU":/ 
~>X5^I403] 


AddMeasureRe 1 a t i onsh i p 


Metadata™cr>API ./X©API*:/ 
^X^A1403] 


DeleteMeasureRelat ionship 

s&ifcji s racogi^^&ii^r * ) 


Metadala™OAPI [-fr— A <0 API -*)-:/ 
i"X^A1403] 


UpdateMeasureRelationship 


yetadata TB (DAPI ED— AcOAPIti-:/ 



[0131] S3^B^Ta^(i»:co-9--t'x^^ 



[0 132] 





i 


AddMeasure 


Netadata™tf>API [■*>■— A© API 7 


DeleteMeasure 


Metadata™C0API [If— /X© API U" 7 


UpdaleMeasure 


Metadata TV1 <DAPI [•*— A^APH*"/ 
->X^A1403] 


CetAIlAnalysts 





[0 13 3] ~t7*>h * /^f7D/|^W-t'X$: 
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[0 1 34] 







AddSegment 

i 


Metadata™CDAPI [U— AWAPIU-:/ 
->XxA1403] 


Upda teSegment 


Metadata™CDAPI [-»}— -A«DAPIi}-y 
~>7.^A1403] 


DeleteSegment 


Metadata™^) API [■*— ACDAPl+f:/ 
xXxA1403] 


GetAl (Analysts 


v-X^A1402] 



[0 13 5] flRB-fe*y bT^rcO-fe^ya^l 5 1 5(3 
&<?>?7X. -t^Srfc-fe, clntBui ldRelat 

ionshipDlg 4 |t<cl n t Bu i 1 dM 

easureDlg^ clnt B ui IdSegme 

ntDlgfc^clntBui ldRestrict 
D 1 g (i"^TMFCc7)CD i a 1 o %<Wf9"7^) 
<7M >X?>*(,z£^XfflfflZtl&. a-fl40 5^ 

tS:aiS?L/i*&. c IntJeasureDefD 
1 g& J:t/c 1 n t_S egmentDefDl 
Sot? httBR^T^U^hiSilXI nfoFrame 

[0 1 3 6 ] : 

Sfufi: <=5r^Cl^ £3jrf ^ >y -b-i^jL— r 14051: 
2fLT3^2*L&. JL-if 1 4 0 5£l±Z0MmztL~> 

Mod i f y (3EJE) <0*§*& : 



[0 137] Ti-UXh * t>^>frn/' *.y? 
XI 5 1 3 tCioT^-ifl 4 0 5ti»5BOI nf oF 
r ame™ ZnteKSZ:'*? 
h (T1£#BS) . £tz. «itc«koTi--iri40 5U; 
1 -^cor^ 'J x blztt-f&^lri/'sL- y v-Zis 

r-f Tu^liJL— if 1 4 0 5**ir:/*W rn/, -r=5r^ 
^ Measure (SOS^SS ) „ Segments 
(-fe^OOM T i me S 1 ice (^U^7>f 
X). Schedule ;P) . fcit/Tr 

i gge r ( MJtf) £^TT& «t ^Mffi-f & . 9* 
• >f ^-7x-X • V-yis^^ 1401 <0fl&OSR# 

*y-/W<-. ifc«4v*-y* 

[0 138] jl— if l 4 0 5^Uv7^MJXh£ r s 
ave (fiU?) j £fc*± TSaveAs <£fy£ottT 

«#) j 5:K^r^yxhi7)jiTS^r^t#. c 1 

n t_An a 1 y s t She et^To/lic 1 n t 

I nf oFrameReque s t Jt^flsjL? hSr'f 

y^^yyX-hf|» e c 1 n t _An a 1 y s t Sh 
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[0 139] 







HevAnalyst 


4 0 2] 


UpdaieAnalyst 


4 0 2] 


RunAnalys t Now 


InfoFrame^litAPl [■* — JWAP 
I ^^Xt-A 14 0 3 


SetFrancDef in it ion 


Inf oFrameRecues t (OA P I [V 

*~5?* . ^-/^ X5 i A 1 4 0 2] 


Ge IFrameDe f in i 1 i on 


InfoFrameReQucs t (OA P I ["7 
• t^->XfA 1 4 0 2] 



[0140] c 1 n t_An a lystSheet;7 
XlitfOT? 7^, 3r;b*>. c 1 n t_A n a 1 y s t 

MeasurePage, cln t A nalystS 

egmentPage, c 1 nt A n a 1 y s t T i 

meS 1 i cePage, cln t A n a 1 y s t S 

chedu lePage, clnt A n a 1 y s t T 

riggerPage (t^tMFCtOCPrope r 
t y P a g e <W79 yX ) <Wf?4 To^Sr>f >X 
^>->-X-h-r^ e iilfettJL— if 1 4 0 53^JB#^SI 

/PfcWtfrt"*. Tt'Jxh • t/yXfAl 5 1 
3(ic 1 n t_Me taTre e PyX&XXfc 1 n t 
JeasureMap^XMfl), *tlt>lZM 
etadata^OAPI JrlLTMe t ada t e 



[0 14 1] c 1 nt_Ana 1 ystSheett/ 
r>f Tn^fcta.— ifl 4 0 5c7)rt*JXh - mzrom 

~t)l± clnt I nf oFrameRequest 3f :/ 

* if:/^7^^igSil* Xiry^-W 

^^i/a-'Jy^U^^vh 
- x*ri/^—"7 • ^/y^fA 1 8c7)^^tz 
BM£HLTliT!E#!«> .cln t_An a 1 y s t 
MeasurePage ii^S$$:fl!!W/yXf A 
t:»LT4f 5. 
[0142] 



te/as nutans 


ItT'yXrA 


Get Name 


InfoFraneDef ini t ionCDAPl 






SetNane 


InfoFrameDef ini t ion© API 




[^* — • -^^'>X^AM02] ; 

! 


CetFrameType 


InfoFramcDef ini t ion© API 
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oe ir ranie j ype 
(.7 \s — A • ^*S^-r-5) 


1 n I Or Tamvuc limit dlvy/lr 1 


GetTargetMeasure 


InloFrameDeiini tionwAFl 
[^*— v-r • 7^ 7.x A 1402] 


SetTargetMeasure 


InfoFrameDef ini t ion<£> API 


GetCoEpar i sonMeasure 


InfoFrameDef ini tionOAPI 
[T-^- — -Y • •y-yxXxA1402] 


SetCompar i sonMeasure 


InfoFrameDef ini t ionOAPI 
[v* — • •y-^x7.^A1402] 


GetAddi tionalMList 


InfoFrameDef ini t ionOAPI 
[V^-v'r • +>-:/;> 7. -f-A 1402] 


SetAddi t ionalMList 
(iiJPOM 'J X h $-a55t-rs) 


InfoFrameDef ini t ion£>API 
[T* — 5?-v • it^">'7.7 L A1402] 



[ 0 1 4 3 ] c 1 n t_An alystScgment 
Page {i^am^^^^^MznLX^O . 



[0 144] 
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GetTargelSegment 


In i orrameDei mi t i onWAPI 
[t*— itr • -9-^>-XxAl402] 


1 

| SetTargetSegment 


In f oFrameDe f i n i t i on<D API 


Ge t Coinpar i sonSegmen t 


InfoFraneDef ini tioncDAPI 


Se tCompar i sonSegmen t 


In f oFrameDef ini tioncDAPI 
[-?*—i?*Y • U b :/>'Xt',M402] 


GetAddi t ionalSList 


InfoFrameDef ini tioncDAPI 
[V^— v-v • -t^^T. 5^1402] 


SetAddit ionalSList 


i 

InfoFrameDef ini tion<DAPf 
[v*— • tf:/^* A 1402] 


GetPar t i t ionLis t 


i 

InfoFrameDef ini ti on<DAP I 


SetParti tionList 

(At— 5^ S'a > • h£&3£-r-5) 


InfoFrameDef ini tioncDAPI 
[^*— • ~9*:/~>7^A1402] 


GetParentPartition 


InfoFrameDef ini t ionCDAP I 


1 

SetParentPart i t ion 

- - 


InfoFrameDef ini tioncDAPI 

| [V* — £^ • •^^->Xt : -A1402] 

i 
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CetPer iodType 


InfoFraneTiBeSliceCOAPI 


SeiPer iodType 


Inf oFrameTiieSl iceOAPl 


Ge iAna lys is Type 


Iii[oFraueTiae5l iceOAPl 


3e IAna lys is Type 


Iof oFraucTiBeSI iceWAPl 
[T*— i?* ■ it T^:*^ A 1402] 


(re lYenrType 


InrnFranpTiiiP^I ir*»(7>A7M 
iiiiiiriABici in go i itc w ru ■ 

[v^-vv • tl-> r >'X^A1402] 


SetYearType 


InfoFranefineSI icetf)API 

• tf-^*>X^AU02] 


GctTrendJnterval 

1 


lnfoFraneTineSliceOAPl 
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Se tTrendln terval 

(M/> jecDiaiwnsiB 


i 

i 

Iniorramei ime51 ice(E>API 


GetDuration 


InfoFrameTimeSl ice<2>API 
[V* — v+> • 1tyf>X7 : *iU1402: 


SetDuration 


InfoFrameTimeSl ice<7)API 


GetNumDurat ion 


InfoFrameTimeSl iceCT) API 
[V*— S?* • -9"^£>X^A1402] 


SetNumDurat ion 


InfoFrameTimeSl iceOO API 
[V*— • t^yXf A1402] 


1 

: GetBasePer iod 

! 


InfoFrameTimeSl iceCO API 
[v*-yt • -tf^^XxA1402] 


SetBasePcr iod 

i 


InfoFrameTimeSl iceCOAPI 
[V* — V* * 1fy>'XxA1402] 


. GetBaseThruPeriod 
1 

(S 7^ <D £ ft <D & fffl * # -5 ) 


InfoFrameTimeSl iceCOAPI 

i 

[V^ — • it^^>X A 1402] 

! 


SetBaseThruPeriod 


InfoFrameTimeSl iceWAPI 

| 1 


GetCompPeriod 


InfoFrameTimeSl ice<7>API 
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In f nFrampTi meS 1 ice£)API 
[V* — 3** • U-^ z>XxA1402] 


uyci a I UJ 


T n f nFrflmpTi mpS 1 i ce(D API 
[^r*-v* • -y-y->7.7 L AI402] 


GetTimeSlice 


InfoFrameTineSliceCOAPI 
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ePage \tdmW£i:ib<nV7i'Ar'J*&ttLXft [0148] 



mm 


1 


GetNumlnterval 


InfoFraneSchedulecDAPI 


SetNumlnterval 


! 

InfoFrameScheduleCDAPI 
[T^ — is*? • +J-:/>7^A1402] 


Getlnterval 

( m m m m 


InfoFrameScheduleOAPI 
[V* — . 7^ A 1402] 


Sctlntcrval 


InfoFrameScheduleOAPI 
["7* — S?* • 1t^'->X7 : -Zsl402] 
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] — _ 

GetStar tDatc 


1 

InioFrameScneduleCOAPI 
[^* — >^ • -tf T/^X-r A1402] 


SetStariDate 


InfoFrameScheduleOAPI 


GetNunLini t 

i 


InfoFrameScheduleCDAPI 


SetNunLimi t 


I n f oFrameSchedu 1 eCD AP I 


GetLimi t 


InfoFraneSchedule<Z>API 
[T*— it* • ij~:/>'X'r-M402] 


SetLimi t 


Inf oFrameSchedu leOAPI 
[v* — S?* • 1* t-^1402] 


GetScheduleFlag 


i 

I n f oFrameSchedu 1 e (DA? I \ 
[V* — S?-f • it^>-XxA1402] 


SetScheduleFlag 


In f oFrameSchedu ieco API 
[v*— >>r • ii-> r >X^A1402] 


GetTriggerFlag 


InfoFrameScheduleCDAPI 


SetTriggerFlag 


In f oFrameSchedu letf)API 
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[T^ — z? *r - It A 1402] 


SetSchedule 


InfoFrameScheduleOAPI 
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mm 


■try a 


GetTriggerList 


InfoFratneTriggerCDAPI 
[V* — v-ylty^X^AHC^] 


SetTriggerList 


InfoFrameTriggerCDAPI 
[v* — ^-*:/^;* 7^ A 1402] 


GetMessageFlag 


InfoFrameTriggerCOAPI 
[ -7 * — * U" ^ x X A 1 4 0 2 ] 


SetMessageFlag 


InfoFrameTrigger(E>API 


GetFrameFlag 


InfoFramcTriggerC7>API 
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SetFrameFlag 


1 


GetAnalystList 


InfoFrameTriggerc^API 
[T-^. — y tU"7"yXTA 1402] 


SetAnalystList 


InfoFraneTriggerCDAPJ 
[V*~;x*1f:7:>X'T'A1402] 


Operator= 


InloFrameTr igger <?>AP I 
[ V v > X T A 14023 


GetMeasure 


TriggerCDAPI 
[V^.— V* • U" xA 1 402] 


SetMeasure 


TriggerCOAPI 


GetOperator 

i 


TriggerCOAPI 
[T^— ^-r • 1f^f>X^A 1402] 


i 1 

SetOperator 


TriggercoAPI [V* — • >^> 
5=- A 1402] 


GetOperand 1 


Trigger^) API 
[-?*—i?-Y • *^^7,^A1402] 


GetOperand2 


Trigger CD API 
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(*^7> H 2 £^5> 


• -*:7vX^At402] 1 


i up e ran a i 




SetOperand2 


Triggered API 
[v* — ^-r • 5^ A 1402] 


GetValuel 
(ttl 


Trigger^) API 
[■7* — S?* • tJ-7 r >'7:7 i A1402] 


GetBalue2 

(ffi2 &nz>) 


Trigger^) API 
[■7*— J?-*, . -y-y'>7.5 : -A1402] 


i 

1 SetValuel 

(«1 £K5£T£>) 


TriggerO>API 
[v* — 5?* • if ^ ->7.-r A1402] 


i 

i 

. SetValue2 

it 2 saisr*) 


Trigger^) API 


Operator= 


TriggerCOAPI | 
[T* — * Ity v'X-r-A1402] 


SetTrigger ( MJ #£I£5g-r^) 

i 


InfoFrameRequeslODAPI 
[T-^ — yt^^'/Xri 1402] 
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c 1 nt MeasureDl g 
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[0157] I nf oFrame™^ta- V • +7 4 
VH^lSl 7«iBM_bt*I nfoFrame™ £^ 
^th (Tia#S§) . InfoFrame™^)f-^ 
t'^-vi 5 1 7U:jl— <f 1 4 

InfoFrameTM^-Vlilnf 
oFrame™ h^fe^affiS^-— ** 
fcHflW**. InfoFrame™hWl517 
fWiInfoFrarae TM <07r 
4A'tf>*H?F*5J:V*tf>I nf oFrameTM^/y 



[0158] InfoFrame™OtV7-ty 
jx— ;U 15 17 <A*W<— I^OllMBi S a v e A s 
tZttLXi>&*>tl&. 4(7)InfoFranieTMf^ 

THT^7 7 * X— ^3&*«*7 h^77^f 
• ^^-i/CC^^iX^ ) . f UASC I I **: 

InfoFrame™OhV7-7^F71 
517lilnf oFr ame™ cOT'J yMSSgtf^ 
— C:cO®fgiiMFCcOCDo c ume n t*5«k 

t/CScrol 1 V i ew^7^t:J:otM^I>» 
fttzK^lvcfts&ft*. I nfoFrame™ COt'j. 
— *7 * irrS/XT-A 15 1 7li&<aH#£fl!!Wr:ryX 
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i/Xzr& 1 


UpDatelnfoFrane™ 


ManagerOAPI O*— ^ v ■ ^^^7.^^14023 


Dri I IDown 


ManagertDAPI [V^— i?^ • if7v'X5 L A1402] 



[0160]A'-t(Perser) :clnt_Pa 
r s e r9 7?,\r<%cr>3^<OWffiXz£~>X7"7<4Tyy 



1 2(C»LTHTML(?)/^affi£llRtS. 
[0161] 
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doParse 



I n f o F r ame™^)ta-7i:<koTI?aj$ 

fLTfnfn^HTMLr-^OlO© 
IS**blT^5 c 1 n t _T a gt^yx? 



SaveASHTMLJinicode 



a— IF 1 4 0 5^HTML77-fM«#t5J: 
om^Lfch^\Z^^ — zy^ 1 4 0 2 Kcfc^TP? 



' SaveAsHTMLJVSClI 



xmsc i i ttTttaisn^-^^tt 



[0162]t'j.-7(Viewer) : b'^— >7l±M 

TUS^iX^o ^7Xcl n t_Vi ewerliCSc 
r o 1 1 Vi ew (MFC) ^W7XtW. 
^7X«ie«r^^n-;uSr««i-S. fv^o 1 nt_ 
ParserDoc liC Document <7y*T79 "y^ 
T*£. £&mz^ «iU;c 1 n t_P arse r *7 
h?:>fy^^yyX-hUf(30HTMLf-^ 
c 1 nt_Viewer(if<7)Jg 

-7x^- t/y^f^l 4 0 1 fc:J;oTflg;b*l.6. 
c 1 n t_Tr e eC t r 1 MFCCOCTre e C t 

u^- 3yhD~;k c 1 nt_MetaTre 



c 1 nt_MetaTree Z 03> bD- MiKM 
Wfcy*—~?v hTMe tadat a T h 

lnt AnalystSegmentPage, cl 
nt_Bu i IdSegmentDl g x c 1 n t_R 
estr i ctMeasureD 1 g , 
[0164] c lnt _T opLevelSegmen 
t C omb o COTyhn-;UiKo7W> • 3 
y##7^^itOt^tOMe tadat a™^h 

: c 1 nt A n a 1 y s t S e gme n t P a g 

c „ c 1 n t_B ui IdSegmentDIg, cl 

n t_Re strictMeasureDl g. 

c 1 nt_Durat ionCombo CCDrJ^hD 



(4 1 ) 
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c 1 n t _ A nalystPeriodPage, cl 
n t_An a 1 y stSchedu 1 ePage, 
[ 0 1 6 5 ] c 1 n t _0 peratorCo m b o 

: c 1 n t_An alystPeriodP 
age. c 1 n t _ A nalystSchedul eP 
age. 

c 1 nt_Dat eEdi t ZCO? > ho— Mtu— 



ley*- 7.yht5. iX^^TD^dtfOrj^ho— 
/Ptf>1f:/?7XT**. :ctnt_AnalystP 
eriodPage, c 1 nt_Ana 1 y stSch 
edu 1 ePage, 

c 1 n t_Re adOnlyListBox Z<nu> 

^^1^3 y h 7 XT'* l» . : c 1 nt 

_Bu i IdSegmentDl g. 

c 1 nt.MetaTreeayh 0-;Uiffi^f ^ ^ 
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— i 

ifr/^X^A 


Get Segment 


Metadata T *<0API [If*— A ©API-*:/ A 
U03J 


i 

GetPartition 


Metadata™cOAPI [U— ^©APIit^S'XT- A 
1403] 



[0 1 67] c 1 nt_TopLebe 1 Segmen flOTi"*, 
t Comb oliffiW^f A/i^£7)$W-t'X$: [0 168] 



GetSegoeDt | Metadata™<DAPI [•**— Atf>API1J-:/~>X^A 



[0 169] c 1 nt_Me asu reComboM [0170] 







GetBas icMeasure 


Metadata™(DAPI [it— A* ©API :/ xXf A 
1403] 


GetCoBDQSt tMeasure 


Metadata™C0API [it— /t^APIit^^X^ A 
1403] 



[0171] 7h'i^hl/-^>^-7x-^l 5 1 6li2o<O^X?. ^--if • Tft^>h 
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• hT'/A &i:X/Me t ad at a™ bVl^i* 

^To^KioT. MDTA (TKS-XhU-* ) (i 
o^V^S, ^XV-K, *5£t^-if • 947*^X5 

Metadata™t';W:iot, MDTAiix^f 

y^X"r^^4>^)c 1 n t_U serLogi n ^ :7X 
SfflJBt"* . Metadata™ bVl^OBfflliU— 
A'i7)AP It7yXfAl 4 0 3fc:J:oT«ttS;ftS« 
h /Ch'-f^TsOM etadata™ ®#g$rflj«-r^ . 

Ziixii c 1 nt Communi cat i o n s , C 1 

nt Dimens i on, c 1 nt Attribu 

te, clnt B a s i c M e a s u r e$5<kZfc 1 

nt_Segment^7XW-t^$:#tf. £ 

tz. Zititf-f ■ ^x7A^xm^-*7(:r;« 

-fhtz^Zc 1 nt_Schema;7^(>i3, 
[0 1 72] ■ V- T%*»h • ^7o/liMFC 
CO-*}-?? ? XX*fo& . c 1 n t_U se rAccoun 
tD 1 g(^>f >X^VXfcJ:oTiSfl»Sil£. c 1 nt 
_U serAccountDl g j^X^AOffilcOgfcfr 
CTlT^tl)^y^-7x-X(i, CDialog 

XsWBIBSfUtfiL DoModal ( ) ifflVihZtlT 
%CT>y4Tu7*m7K?h. DoModaltStW 
ffiUi. x-if 1 405^ *-rV-b/lo ifcii r?u 

[0173] Metadata™ b'/l^tf)^ 7o^ 

ItthZb&TZ* ^ t yt;h ^jfUMetad 
at aTM t^^feBiai**-&i4:3&«-CS6. 
if— Ktf) r 7U-Aj (iMFCCOCPr op e r t y S 
he e t«01f;/^^XT*&. ;?Xc 1 n t_Mas 
terSetupHiotH^ill), clnt_Ma 
sterSetu pconyx h ?9 9\$%r¥4 7o/ 
r^— i/j (clnt_AttributeDef in 

i t i on, clnt A ttr i buteMappi 

ng, c 1 n t _A ttributcVal ueDef 

i n i t i on, cln t Au tomat i cSeg 

me n t s , cln t B as i cMeasureDe 

f inition, clnt BasicMeasur 

Map, clnt D imensionDef init 

ion, clnt Joins, clnt T i m e D 

imension, clnt Y earDef i n i t 



ion) r fc iz i o-f -m yx^y^^«t^ . 
^-isi±zn&m^zti&mz rw-r-i* j 

-KSil*. iilllMetadataTMt'^JIW 
izayxhy? bLXZ<?)4 >*9>X±XV oMo d 

ai o *ofvaj-tflfi<o^7>fryb • rru^-^a 

[0174]* >?j tiif— yitOAP I 14 03O 
Me t adat a T M ^XlC^&^ajL^&LT. 

P I 1 4 0 3$rilLT^^-^^^0T-r^<I t^io 
T tf^VCttLTJESr**-*. c 1 nt_Mas 

t e r S e t u piifi6ffl$ix-5>*^-f TOM e t a d a 
taTMCJttSlo^'jy; • 'J^hftUt^S. 
#UXhii0flKU:Oc Int.SetupObjec 
t*7i?3L? hS^X/CV^S. c 1 n t__S e t u pO 
b j e ct^y'x; Mi2oc0f-^ • 

1 OliC Object (:^tfl> W y ^T'fc 
0,^5 lO*4c 1 n t_Ob j e c t S t a t eX^ 
jL^lz-yHV (enumeration) tJS, c 
1 n t„Obj e c t s t a t e|j:4O(0i, 

^, STATE_EX I ST I NG, STATE NE 

W, STATE DE LETED, STATE MOD 

£. jl— if 1 4 0 5**Me t adat a™ ^T^x^ 

V9 • UXMi^/yx^hSra-f l 4 0 5i:W 
LT«S***jC^ fLTkW^'x^hU- T14 

UV? • yxMi r^^vHr;Uj r«#j co** 

>C;: e koT*>ffi;bfL&. jl— if 1 4 0 5^ r ^r-v>-tr 

<n*7*J*? Yifitm^tlh. JL-ifl 4 0 5** r « 

WSTATE_E X I ST I NGT'fto/^. * 

t-A'iOMe t ad a t aT m ^Uil^il, -£ 
LT*«oyxh36^ttH»3ft6. f^STATE 
_DELETEDt*ofc«*. *<Z>3T:/^x ^ Milf 
-A±<0M etadataTM jj^HiJBfcSfu * LT 'J 
Xb*»fctBfll»Six£. fWSTATE_MOD I 
F IEDT'J)^^, ^^y^x^b«^-/<±C0 
Me t ad a t a™ <7)i£XWgi$tL. *LXZ<7)*7 

[0 17 5] r^f-Kj^-y'^ rg^j ^> 
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[0 1 76J 



■5V />'>3> 




lift 
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<&L> 
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[0177] -x-if^w<3 4±<0M e t a d a t a 

9 hlZttth r ffl{&tttlt>tltt7i;* 9 h j liD A I 
t/^fAl 4(cJ:oTffii&;*ix&. v*— * ^ 
4 yH»>l 5 1 2teV*->-> • t/yXfA14 02 

£>^>. ^>f-f y^cOI n f oF r ame™ (3^6 
tiWREWMc* 7*frr. T-*-yxK fcJltfl nf oF 

[0 17 8] 4lI07^-y> ■ >Y*t\ 5 12 

■ InfoFrame™£0'jXh (^^T^OI nfo 
F rame™<7)777 h^r'jXh) 

*/W4)«t><D InfoFrame™i> ttfT-f* V X V 

• 'O'tm yyco^j.— (da i l 4cottS4 /v ;yf 



4 V/CiotV^ I nfoFrame™ ^)77"/ h 

D7r^»8tv*-y> - Vh^Y*? 15 1 2Cio 
TlhK— hSiX*. r-MfXhcOUXK InfoFr 
ame™CT)UXh, *5j:tf ^sr/W - b*jL-t> rji^ 

Jteti-MxKLhtf) I nf oFr ame™ ^Y^v^h 

cot 4 h v fc fc =Sr 0 # & . 
[0 180] ilDC7)3^7^-^ 
^Ttrt'JXh^'jXh, I n f oF r ame™ CO 

yxK y*)V? - b'jt.— ) &mw7isXTJ±frt>co 
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GetRootFolder 

op- hen? 


Xf A 1 4 0 23 


GetTrashBin 


1 4 0 2] 


GetAl (Analyst 


X-f-A 1 4 0 2] 


GetAl UnfoFrames™ 
(T^TroinfoFrame™£^£>) 


7^-;tAPi [-7*— • u-:/^ 

XrA 1 4 0 2] 


NewFolder 


7^-vtAPI [V^— i?t • t^y-> • 

i 
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XfA 1 4 0 2] 


RemoveFolder 


XfA 1 4 0 2] 


MoMeFolder 


1 4 0 2] 


SetFolderNane 


n-^tAPi [ • vyis 

X-r A 1 4 0 2] 


MoveAnalyst 


7?-ytA P I [V^ — • if 7"^ 
Xf A 1 4 0 2] 


RemovcAnalyst 
(7±'JX h*ft0MK> 


n-i/tAPI [-7* — 5>+ • 
X^A 1 4 0 2] 


MovelnfoFraiae™ 
(InfoFrame™ 


XrA 1 4 0 2] 


RemovelnfoFrame™ 
(InfoFrame™ 


7^-/tAPI [V^-v 5 ^ • -^y-> 
X^A 1 4 0 2] 


EmptyTrash 


7^-^tAPI [V^-yf*?'^ 
Xfi 1 4 0 2] 


GetChi IdFoJders 
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TA 1 4 0 2] 


ue 1 1 ni or ratne 
(InfoFr ame™£fi5) 


rA 1 4 0 2] 


GetAnalysts 


i — ■"- - — 

1 4 0 2] 


RemoveFolder 


7 * )V¥ API [V^-^v • -y-^-^X 
^•A 1 4 0 2] 


RunAnalys tNow 


InfoFrame ™f£fi£ A P I [■*— 
A<DAP I t7"->7fi 1 4 0 3] 


ViewInfoFrame™ 
(InfoFr ame™£ 


InfoFr ame™<Z)t'a- >7 • «^>f 
>HC [a— if • -f — 7i-X • it 
:/->X^A 14 0 1] 


run Analys tBui lder dialog 


7t'J7 b • k';i^ [ol— -9 s • -f | 

7i-X-t7"^fA14 0 1] j 

I 
1 



[0 1 82] S4^-y> ■ yH^, r^ v ^ x£^-T£ 0 
>f - ^ jl — j {iffeWT'^^A^^^co^-h* [0183] 



GetStatus 


Info 


F r ame T "MAP 


I [-*•- 






I -tf^^X^A 1 4 0 


3] 


Cancel Analyst 


Info 


F r ame™fmAP 


I 






l*}Zf>>XTU 1 4 0 
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^-XlZ&^X^ r 7l/-A j aiO/ift^O^^^.. C 
1 nt.Manage rWnd <MFC*^<OCMD I 

Ch i 1 dWndW^7X) (cioTS^il^. c 
1 nt_ManagerWnd ^/y x ^ Mif il^'i: 

[0 185] 7V— A • ^K^*^ r^y^o- 

^2gc7)MS-Wi ndowsOTyhD-yW;^ 
-f&5*y^— (wrapper) . ^7Xc 1 n 

t _ A nalystCtr L clnt_InfoFr 
ameCtrl, c 1 nt_Pend i ngCt r lii 
-HvWlCL i s tC t r 1 *>>£>«*L. r ^7Al 

c 1 n t_Fo 1 derCt r HiCTreeCt r 1 
UMDT7^ ^ »J -*<0PgJf SrSl^rf 
S. Zl\ba>? 1 7Alt*tltf&im& r style (X 
94)V) j ^^^CCftffiFLT . c 1 nt_Manage 
rWndCcioT. ifcWcjEtT. >f>X^>-£yX-b 
^Srir^. c 1 nt.Ana 1 y s tCt r 1 
liANALYSTSt-HfeitfFOLDERS^-K 
fci^Tf&bfl. c 1 n t_ I n f oF r ameC t r 
1 iil NFOFRAMESfciZ/FOLDEROT-H 
tC&lvCfi&bi-U clnt_FolderCtrlliF 
OLDERSt- KtefeW^ -f LX c 1 nt_Sav 
eAs^TD/ - (Tt'JXh * hVl^O— 

ffl) IZi-oXi&htl. c 1 nt_Pend i ngCt r 
1 UPEND I NGt-HfcJiJ^TSfcbftS. a— Ifl 

k. *0>F5»/?COV—A * **-f >K">**c 1 nt__D 
ragWnd^^yxSKttfi. *<0fiL *0 

0W"4>. c 1 n t_Dr agWnd{:iih'77^W 

x 9 V £ K o y 7 L T t> J: V ^ i: 3 * #fc & * v -t - 

Int.FolderCtr 1 £J:tfc 1 n t_Too 
IbartM (Wny3. 2. 3 #15) • JL-if 
14 0 5^*V^X 2 1 6 k . c 1 n t 

_D r a gWn diiKa y 3r$*U>7M xA^tAiX 
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^iTA^^API 1 3 3 3\$®L<r>WX>T9v4 TV 

[02 17] 
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^m*! 0-2 0775 1 



■ 


tSiW 


GetTables (7— 





GetColumns (*7A$:i5) 


4- x. S tl fc ^ — -J ) I 6 O * 5 A O 


GetPrimaryKeys (— JK^— £:^2>) 




GetForeignKeys £f&S) 

! 




j ForeignToPrimary 




PrimaryToForeign 

0 


# x. e> n rz 7- — 4" <o a e> n 


LoadSchema 


j 

J&#jb£:ig£\ True^It. 



[0 2 18] -r— * • »>x7^W^AP I 1 5 3 3t> 
CSM 1 4 04i:ilfrr^^^t-afi'^— • 
— )V*mBt&* ir—$ ■ >)i7A^AP 1153 
3 tec 1 nt_Schema;7^+U7t;Ht$ 
flT^&. clnt_Schema ^ 7Xli±Ei7)^ 

■ ^W^—BaStSrfii^TV^, LoadSchemaH 



[0219]-fey>-3y - V^VbAP 11534 
[0220] 
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GetSessionManager 



Connect (&&) 



Disconnect (SJUL) 



UpdatetlscrPas sword 
(3.— tftf)/t;*'7 — K£H#rT£) 



[0221)^7^3^ - 7^>hAP 115 34 

tcsMi 4 04 ^ilfrr^^cMfi^-b'x ■ ^e^' 
-x-;l-£fi6Jfl-r-g> • _h£<59-b 7 ^ 3 ^ * >- MS 

Siic 1 n t S essionManage r^AVJ 

• J* >J<<— B8»T*&. ^Xclntjess 
i onManage H4 ("yy/^hyj 

[0 2 2 2] oifl^— t'X(iCSM14 0 4*£e*TCDA 

S. d^^><^raSc^W^COAP It/yXfAl 40 
3^i040£OAPI 1531. 1532. 1533 

b'^^Htgti^-AcoAP I 1 4 0 3 CO* 

^7^h 3 5r-S>. ? 7^c 1 n t C ommun i c at 

i o n s(D*PlZ#y'tz)Wk£tlT^&. 

[0 2 2 33 <3. f-^Sft^f'Jxxyx (D 
A I ) V-7i/*"rJ± 1 4 >-r--* *MMfc>f 'Jyxy 

& • ^^fe^B (Management Di scover 
y Too 1TM 4fcl4MDTfcfcO*tfft&) <7*g2r 
*£SK4. ota-f 14 0 S^IBIHco*^ S^x 

7 h<7)b\x->f ^^iJ.tt/aiBtwfettiPilBO^^Sr 
S*fc:*rcS4«rfc. -£LTMDT£±oTffr£$*i 
5Inf o F r ameT m tf)tl^*Sfl6^0S 
friU-^fc^rt-iifcT*** -X-if 1 40 

5# r St p PJ com±lz^X^t&&f. *<?>Al*Z<7>± 



& :?;*clnl_Sess ionllanagerO 1 ~0 



•7— H*ttSEUJ:-5 



MR (»n. mm. te£Tf9m#iizwx<ommizi~> 
xmwtiz&mztih) co^-ttifinzx^xfem-tzzt 
ffx-Zh. 

[0224] *«^HcoSfKc*3(tSiHIK^ 1 ol4*<0 J: 
KMlt. JL— if # InfoFrame™ c7)^ p ^^- 

i-if 1 4 0 5*»fel4«#Wfc»$*VC Vi&jj5«4. 
BBiWt ixT v -fe ^ >- b # fc* o J; o fc^~r < is 

[0225] *38W^)M anagement Disc 
overy Tool™ ( Wlf&fi/V— ^ ) liWHltf) 

X*-^tfh&. ~?'<XX'ltt:WzLXi>. IZbAst'co 

GMitzx^x, ~m<r>mimtcT-? - ^^r^i^ 

<W:SJp a n. US, h^vif^v-av^^^cox^ 
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z tiizm&tf* ^ a v >y r £ ft-o ^ , x>f>ff-f 

£ v * < ^Wr-7fl>b L TtSJfrT & «! b ifiTZ h . 

[ 0 2 2 6 ] 02 3i±SSnStt 16 0 1 tSX/CU&JL 
— r 1 4 0 5^J:oT»filES<l3tHJit*LT^-6. ^> 
-1ft* r«nj jgfti 6 0 l fc*t/cv*T. attumt*) 

m&<7)?4 7 j MS l 6 0 3£3St^ *fc*^JItt«0 
r^^> yj x 604£gS!f?U rgit^-j JK 
ttl6 0 5,»:l: r x1f-f^-Xj 1 6 06. ^LTfi 
r ^Xj Jgftl 6 0 7. fci^A-f^ 

» r^^^h j li fr^i—x^mftmi/^y j t 

[0 2 2 7] r^OX^r— AtwioTMDTcOffe^^ 



*BOK^^f vtUtLT. C:ix^<^-if 1405 

^T4)»Jt#** r 55ttffl^"r % yj Srft^Tv^fcia 

**\ **t«Ctf5««tilJlW)MetadataTM 
fc LTfHfrf & w k awe* £ . 
[0228] *¥tffltoWS&ttl&~Vfcnp>*rx 

&. ""-rif^^-X^Sttffl^^Vj #JL-ir 1405 

COXr-^fV— SrfiHfL. InfoFr ame^ M 

p a pj iXLfoh. 
[0229] 















MC 








Steffi 


MC 




















MC 


^if-f^-X j ^**.y 
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MC 










MC 










MC 






±m 


G a pCT>SlSr 




Gap 
















Guess <Df&&3 




Guess 








MC 










MC 










MC 









[0 2 3 0] ±MZ<?)*:7'*>hlZl:^xm2 4t f Z*kZtl 

>Y\±^<^tiwm%hmmizm^h^tm&$>*) . % 

6. 

[023 1] WfcZ&tm+itilblZ* ^—t4 1sb> 
2 4 * 0 2 5 (C^ ?ixT V J: -5 H LT^-f -f 

So w020tfO«fct:(i^Src^^^ 0 
[0232]iH:^i:, MDTf-^MiW yf 
V is* >X (DA I ) tyyXfA14i^7^7yh 



(DSM) t/yXfA 1 6 £c0f3(£Ao"C . DA 
I 14 (fcJ:tfDSM16) liTyVlr-isBy • 
A3 2±tfX^h773 0hf-^ • »)i7A^2 
4 4;OlSfc*&. DA I 1 4ttJL-if3S«Bf?LfcI n f 
oFrameTMH>X^>yX-hf^^ -f- L 

^Metadata™ Sflti «I SfiSti . ^ 
^MetadataTMIl ( 1 ) ? - ^xTa*) 

(2) I n f oFrameTM<0*C8lWW 
^x^Xh$:S«-rSi!l^SSc7)RI^. fccfctf (3) 
«fRI^I»|j«ftJt4>*ifc M e tadata^M £SM\ 4 
DA I 1 2frt>ft&LtiZ0> 
Me tadata TM t£*t-r^|gSS^*ISL. 4fc. 

< r>frcom<vmmcommt: . ±at^5:DSMi 
at=. da 1 1 4(i^5-rr>h 1 2**:tt*^.i- 

[0233] W&mrfvJT* h/^-^^H-ii. 
2«S<0D A I *T7is^J± 1 4 Zlgfcth . SlOS 
SODA I 1 A\$9v4 T>bl 2frt><Offimzm-h 

(f. ?7>f7yM 2li7^f ^/5:MDTt7y3 V 

-DAI (y'JT^DA 1^) A^<ife<05H*Sr« 
m2c0ffiSODAI 14i±M>^««4fctt 
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InfoFrame™ (Dfemt: h Ti~ 

a. mm®) a^iTOt* 1 * 1 ?, ^txm^rf^ 

(ay$u>h) fcHft£ix&. z&fJzr&DAl l 
4\$ay%vybVAl b^oMMX'C-DAl fciw 
tlhZttftbh. C — D A I I nf oFrame™ 
S^:iS§lTS-DA I izX^XXX—y ( s p aw 

n) ztiiz<m%^Tcommtf5-£t>tLh. & 

T~f&t. Ztll±*<?>&mcD I nf ©Frame™ £ 

[02 34] S2 6ii:DAI 1 4fc JlXteO^^Xx 
Afc^^JJcoMDTcorjyjK— *y btcofflco^ — J&tfj 

(S-DAI) 1 4A^a^*$:if-t'X-r&^ 
7V h/t-A' • ^ y'a-/P { C SM ) 1 

404£iILTS£*U C1<0C SMte?^>f T>hl 2 t 
^T— ^3 2 b^cnmmiUWth. Metadata 

mXL&XZJtW&i («&*) 
<m^5t^. S-DAUz£^T9m$tlZ>. WtftL^ 
mzX-oX. S-DA IiiMDTc7)Me tadata 
tm<t)^— 7)l><7)t£t t Z'&&tlX^hMe tadata 

T M lc^&x-^£<£tfx^-v££# (dsm) 

6WSftvg-;b-£&. S-DAIiiLucent 
Technologies 4fc#) Bell Labor 
at or i esHA#tn, B»r-*ai»£lBI 
't&X:isbCDi'X J rJ±Tfo& rc 1 a s s i cf/^f 
Aj ^S3:U:j;oTIi^Mt^, c l as 
s i cir^s/^'r^li-fe^vhBJio+OSRLv^-- 

e n u m m d t M e s s a 

UNDEF I NED, 
CS_LOG I N, 

SC_LOGI N RE S 

C S GENERATE 

C S GET I NFOF 

SC_ I NFOFRAME 
CS_GET_I NFOF 
SC_ I NFOFRAME 
END OF ENUM 

> ; 

[0 2 38] md t_Me s s a g eTypeliMDT 

izx^TmrnztLZ-r^xcD* * ?4 7&jm 

e n u mtW. mdt M e s s a g e frh&fr 

tl&&??X1,ZffLX . md t_Me ssageTyp 

md t Me ssageTyp e O^WiiMDTcO"^^ 

class mdt _T I n S t 
m InStreamHandle 



*Ut: I nf oFrameTMtCJt^S*?:, t-A'co 

[0235] T^U*h£^-f &<r££TJ-— *f#*®:£ 
-T&fc. 3^i/yhDAH4B^fUA* 7 fti: 
£^>X£jR2ti (UV-^3WH*&) . -cLT-r<7>a 
^1/yhDAl 14BKT^ll*h^£3$^+T^^ 
TOtSS^SS^^, ri^UVhDA I l4BttiJ:t3 

^offii^r;prf yxAfciixc sm i 4 o 4*»fe*R 

SiX^Me tadataTM £fiE^>"C I n f oF r am 
C SM^ i/a-yn 4 0 41^ lo 

2t>tzmL<Wm$tLh£olZ^ CSM14 04<0h*y 

[0 2 36] ^O^v-b-^- ^-/i/>"7<7)m\\±5r> 
7^J5 il^ 1 O^lfi^m d t_Me s sage 
T-ypej&^fcjfiS*!*. ^J^(iMDT<0*<^&^ 
TcotzUbc^JL^ — ?=5:ffi£KrO„ md t_T InStr 
e amHa nd 1 eiSil/md t _TOu t S t r e a 
mHand 1 e te^ft-fixA^fc J^ffi^O* y-fe-S^ 

■^hi;-^A^K;Pt*4. mdtjessag 
e(if^TC0MDT^ • 9 

yXX'Jb%> , dai M assageHand 1 erli 

■ da i_Me s 

sageRegistr yti;* v-fe— ^ • s^y^^COU 

[0 2 37] mdt_Me s sageTypeiiHTt: 

g eTyp e { 



PONSE, 
.1 NFOFRAME. 

R AME STATU S , 

STATU S , 

RAME, 



[0 2 3 9] md t_TI nStreamHandle 
reamHandle : pub 1 ic cs 
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P u b 1 i c : 

mdt_TI nStreamHandle () : d_mtype ( UN D 
EF I NED) { } 

virtual void Connect ( RWv i stream* ) 

mdt MessageType GetMessageType () 

const ; 

private : 
mdt MessageType d mtype; 

) ; 

[0240]mdt_TInStreamHandle £>*<D* y -fe- i/<D? 4 T£ SttWfcrBMK W7^s 

\±\->x#kh (&mzti&) xmj-ai: - ^>fr^#^^o^wN'-Ria^set-r^. m 

*tf *4 T3&«SW>4>fLfc^>H/P"C*S. md t_ dt JessageRegi st r y COJL—*fteZCD 
TInStreamHandl eliCSMt>?i-;H ?^X£flS-3efiS8±2rl\ 

4 0 4*»feAot*S^ -y-tr— • Xh'J- A£tT>y:7 [0*24 1] md t_TOu tStreamHandl 

Tv7~thtlMzmhtl&„ mdt_TInStrea el*aT(iZ£m%tlh . 

mHand 1 e|j:AoT*§^7-b-y • -XMI — 

class m d t TOu tSt reamHand 1 e : pub 1 i c c 

s m O utStreamHandle { 

public: 

md t_TOu tStreamHandl e (md t _Me s s a g eT 

y P e t ) : d m type (t) (} 

virtual void Connect ( RW vostream* ) 

mdt MessageType GetMessageType () 

const ; 

private : 
md t_TOu t S t r e amH a n d 1 e ( ) ; 
mdt MessageType d mtype; 

} ; 

[0 24 2] md t_TOu tStreamHandl U glifflfctJVvtm d t __T I nStreamHan 

Ayh';K'fe§. mdtJTOutSt reamHan <7)X h l>— AtttfLT B^-X *J • ?>fT£SiS 
d 1 eliCSMl 404^lWh'J- AI^v WC##&tf. 

Hr-^$r^frr^^(^^iX^o f^md t_TOu [0243] mdt_Me s s a g e iitlTtwffilSSiX 

tSt reamHand 1 eti>-/Hr— ^- :?-fT£?r 

class md t M e s s a g e { 

P u b 1 i c : 

md t M essage () : d restoreVersion (0) 

, d r estoreFlag (false) {} 

mdt Message (const mdt Message &) ; 

virtual mdt MessageType GetMessa 

geType () const; 

virtual int GetLastVersion () cons 
t = 0 ; 

virtual void SetRestoreVers ion (in 
t restoreVersion) ; 

virtual int GetRestoreVersion () c 
o n s t ; 

virtual void saveGuts( R W vostream 
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&) const; 

virtual void R 
am &) ; 

virtual bool I 
protected: 

virtual void S 

) ; 

private: 

bool d restore 

int d restoreV 

} ; 

[02443 j^feiiflfiWi^^rvhi 2. ^'J 

7VUDAI 14A. 3^1/>hDAI 14B, Xlr-J 
a— ? \ St. T4JV*v*2 5 1 3t<?>f%X\ 9"yA 
7yh/t-^'ti/a-;KCSM) 1 4 04tCi:o 

xmmztih. csMi4 04«»*4^ia?s&is<i 

*fctt»t^ftfc^fc^*lftin d tMessage? 
^*S:IUW"6. SiOmdt_Me s s age{iA2) 
AhV— A$-^A,-CV*ft 0 i*fl<?)m d t _M e s s ag 
elilB*xhy-Amti^. xh>j-Al;iJ;<fci 

Aj-Tft^ *ftV^i, **y*->?tf®S£^y:7T3&* 
£>X Mj-Afc LT SSiM 4: ft . 
[0245] rcOMDT^Hj^^^H^^fL^^ 
;£*5i:r/Jt^te. mdt_Messagei7)i*^7X 

JTSr-XhU-A - ^ifcttxhU-A - T^KTftfc 
A6fioai-W 3 5:BI»Sr*t ,, CV^. CSM1404(icsm 

S imp 1 eSocke tl5j:^c s m S e r v e 

rSocket; ^XSrHSTTft . ■<( TWfv Y 

iiTCP/i py^-7hmt^i> e tcp/ipv 

^•y MiTCP/I P*-y h 7-? 

c sm S i mp 1 e ^^tic s m S e r v e r S o 

eke tAj&£*\ ^ftV^ti. j*fIOc sm_S i mp 
I eSocket h U -A • /< y 7 r £SSX 0 . 
ZtiZ* -y-tr— S?ey*K.4 >x 1 — ^tlxlh^'t^ 
4. 

[0246] c sm_S imp 1 eSocke tiiMD 
T^^-X-r AH"C»SS*lfc 1 » 1 *v -fe- 

^^ilft^-^^C^ixa . c s m S e r v e r S 

o c k e t \tUDT^y^X'rM,tm^< artels* 
•fAfrfc* vH=-^£»*Wt6£i:* s "CS ft J: 3 ^ 
ftfca&fcttirfift. H3 2tc*5^T, ^^TVb - if 

y>-X-rA 1 2tec s m S impleSocketi 

«SrU *<lfettot7X^ ■ 1T7i/Xf 5 1 1 
4>SDAIt7yXfA2 5 12^Sl, 4fc*£> 



estoreGuts (RWv i s t r e 
sRestored () const ; 
etRestoredFlag (bool 



Flag; 
e r s i o n ; 



liVvyefc^V^y h£teffl^ft* 
[0247] 03 2(Ci5Vvc 7X^ -t^fA2 
5 1 UiSDAlt/yXfAl 4A£S;£L*:^tt® 

Sfl^ft^^J-. c s m_S erverSocket£r 

MBWft. 7^^r;t^ ytzsDA i £BHi«-ft 

#\ StrjrttixtfSDAItrWLTffiHSrATV^ftftJa 
*Mi. **ltic sm_Se rverSocke t 
l/O^ft. SDAIf7yXfA2 5 11i^7^fT> 
h • t/yXrA 1 2 t> «/*-^*3fflM-ftrt:ftlC. 
c sm S imp 1 eSocke t£fct$$-?~ft. Ztlj)* 

7 ?j t> h&m&zmmizmmLx^z>B$zm^x ^ 

S D A I 14 Al£<£co c s m S imp 1 eSocke 

tSrWKLT^ft. 

[0248] JL-if 1405 tffcrtf^fcSeirf ft Jfcafcfc: 
T^'J^b v MfckS. SDAIt^f 

Al 4 Aii^C0r^U^b^7 r >f JX^y^2 5 0 1^ 

2Hlr$"ft*:#H3R Lv*c sm S imp 1 eSocke 

t£«ISW-ft. JL-if#^^>?i— ;uai<o. fcftv^ih 
'J^7t'JXh^f7 r $7btl.h, SDAItt* 
COT^'J* hSr-X^^jL— 5 1 8^*tLTiift*tft^ 

ifZ 1 OCO c s m S imp 1 eSocket 

ft. ^i/*-7l8liffl^ 4Wif<T<?)SDA 

Ityy^fA2 5 1 I^^xy^j.-^MC0. *>ftV> 

«hyxrffi^r^yxbtiR*'rftfertcc. csm_s 

erverSocket SrUB^ft. ^^"S^jl— :?#*X 

±(fft^^^*^t¥*JBr-tfth. Xtya-7lics 
m_S impleSocket?: 10flH6LT*4>T^ 
'J^h^f^A 7 f^ • tr^f^2 5 1 3£*fL 
Tilfrtft* ^^-S/jl-^^co^^^jl— ;H!<o. * 
ftw^hU^S^r-MJXh^OU^hSr^XhLT^ft 
ft. ^^{i^ix^Srx^^^vf"LTV^ftft$r^v^T. 
-X^S^jl — ^ti-f^c s m_S impleSocket 
fcBDRLT^ft. 

[0249] fa^vft -t^fA25 1 3*2; 
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mffi%Ttm<?>&M<7)SDA i +ms*T^2 5 1 1 *» 

^^T^U^hSrlRm-r^^. hh^\$. CDAI 
y-7isXy-i* l 4 B*^cor^»Jx h^SriRm-r^^: 
#>(C:. 1 ^>^c s m_S erverSocket 

1OC0SD A I ^/Jifm^ya~7*MoO 

£#><0 »J y-xfflffiT^ & J: ^ lz%h£X\ *tl£8k 

vv-xffimT'Z&xoiztc&h. sdai 

iiCDAI 14BS:^«. CDAI^rt'J 

Xhtd^^S^Srjg-Tfc. SDA Ilil OCO c s m 

Simp 1 eSocketSMU, Wt'JXh 

$rc d a i izttLxmm-rz. cDAicrmmzmntL 

T^hmtmn:. SDAIt/yXfA2 5 13W 

Ocs m S erverSocket irWBULZ^h. 

CDAIt/y^fA14Blif^A 7 ft • *)r7zs 

W)2tlfz1k^-<'lZ^ csmJimpleSocket 

s m_S impleSocket £$§T&. CDAIt 
/yXfA 1 4 B{i*^Oft|!^y>'Xf-^hJi:^ v 

[0 2 50] md t_Me s s agettfl*^7Xii 

£*Tf£. #^>fro> '/-fe-^*tLT. mdt_M 
e s s a 8ei>*t>m&tlfz? 9*0:B*«*3Sfe&s*> 

class dai M e s s a 

pub 1 i c : 
virtual bool 

mdt M e s s a g e & ) = 0 

} ; 

[0252] da i_Me ssageHandle rli 

class dai M e s s a 

P u b 1 i c : 
dai M essageRe 

) ; 

void Dispatch 
void Register 

y p e , dai M e s s a g e C 

eHandler &); 
private : 
dai MessageCr 

c ; 



*. ^7^Ge tLatestVer 

fUGetMessageTypeSHgLt 
fC0mdt_Me s s a g e Ty p e SrilS&WUtfS: 
£>3rV>. Rogue Wave saveGut 

sfcjztfr estoreGuts^/7 K&ISSLT* 

Lj -cab*. r*fc0fca»3Wxfc>-y 

-b-S/- ^7^lo^tJ)$*\ ^ti^^ y-b-^ 

- t^xitzx^xmtttihx y-b-^- ?>rniu<o 

X^Sfic^ro-bXtcfcltSn- Vco^-z/b >Htf>2 

r e s t o r e Gu t s(,Z&^Xf&htl& . mdt_M 
e s s a g e s t;LhIET^»3*Ufcm d t _TO u t S 

treamHandl e /m d t T InStream 

Hand 1 e <fc ->TW V h h V -A£?)fg| 

T\ ^^^ft^/flTtr*-* <I t iZX oT . CSMt 
S/jl— ;H 4 04Hmd t_M e s s a g e#i*fl/ 

[0251] dai Me ssageHandle r(3 

geHand 1 er { 

Hand 1 eMessage (const 



[0253] dai Me ssageRegi stry 

geRegi stry { 

gistry (cs m C o n n e c t & 

Message ( ) ; 

Message ( m d t _M e s s a g e T 
reateFunc, dai Messag 



eateFunc d createFun 
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d a i _M essageHan 
c sm__C o n n e c t *d 

) : 

[0254] dai M essageRegistry 

1 eMessage^VvK^IDli^ 
3SQS$ti7t1^T'D ispatchMessage ^/o 
v^"#-6*B5**»if 33&»**ftt&. BID*** r Sj 

[0 2 5 53 MDW>fr^h'J-i*-Ay 

1 . afflH^oro-b^tt^fWW:^ *y -fe-^ • ? 
<0>f >X?yx (md t_Me s s a g efrh&frtl 

<r-**:-*Sk:o-F-$-&. 

2. Slfiffllorn-fe^<i^co> yfe— ^fcHt* -vte 
— ^^T^mdtTOutSt reamHandl 

F££l£-f&, :Omd t_TOu t S t 
reamHand 1 c 9 Fte-rOP* *y-fe— ^ - 

[0 2 56] 3. 3&flffiS^ro**te-r<0^ -y-fe— 
OsaveGut s VA- KlS£ffioT^O;>< v-fe— 
s^Sr-X v-b— >? ■ X F U— AA,»satr. 

4 . J* *y-fe— £/COs aveGuts>y-y FlifitfJHC 

LZmZ&tsm*<?>7 ?X • ^Vv K«:wai-r. & 
F £ *^>* F U —&*&frt h . 

5 . ^ftffllCO^O-feXiic s m_S endProce 
ssConnect : : Send () SrBftfStiLT. * 
0> y-t-^' ■ xFU-ASriSS. 

[0 2 5 7] 6. CSMli*<OXhU-A • ^S^x 
?F*»6^>f FSrttftU **V<>f F£3fifflk?Wcr-tr 

7 . mdt_TOu tStreamHandle it"? 

XFU-A ■ :t7Vx? hSrffi^f &. 

8 . Sftffik^Tu-fe^tic s m_R e c e i v e P r 

ocess: : Re c e i v e () £ttt&VttiiLtZ& 

9. SfUK^Ta-bXcO+^C SMIi#i- 0*<7>^ 



d 1 e r * d h a n d 1 e r ; 

_c o n n e c t ; 

U-A ■ str^x? FfcSEiftU ^U^Xh'J-A 

£ c s m R eceiveProcess: : Rece 

i ve () fcJtLTSSilfcmd t_TI nSt rea 
mHand 1 e *r>?x 7 h£«»r* . 
10. xh'J -^tff(0Ay F;Wc««Sit4 1 . * 
YMt*e>* v -fe— ^* ■ * A zr^Arcox F U -A 

[0258] 11. SIWc s m_R e c e 

iveProcess: :Receive () fr£>$£tti 

i 2. Sfiffiy^ro-tr^(i^o> y-fe-y • *>rr£ 

md t_T InStrcamHandl e#*£>&f#L. 

T**'*-/**;M^4«0*&\ <I*Uidai_M 
essageRegistry: : Di spatchM 
e s s ag e s ( ) di: ~>X$!M£tl&. 
1 3. 51HBorD-feXtt*^>^ 7-fe-y<7)re s t 
re Gut sR|ft£DfWirt\ >-y-tr-^* faA*7 
f-VS&SttHJ+O*^ ;^Llidai_MessageR 
egistry: : D i spatchMessages 
() CioTM^/i^. 

[02 59] 14. W7*-^restore 

X'ZtliRe storeVersio n^VA-J; LT 
R^^i^cO^s:^^^ (»iUimd t_Me s s a 
ge)OrestoreGuts^V7 F£0ftXifr$" 9 
&IZ^ SJWi*tohJfc^— i'a vcor estoreGu 
t s *<m.Z> • -f^teG etRestoreVers i o 

^ • * w<-£^<o^ f u — A*»fe»*as-ra\ * 

[0 260] 15. %:mZtlfz* >y-t-iS\±ZZX'te 
%<?>m$:(?>7*~- MZ&~>X^h. 7 : 4X'*-y**ifi&. 

^>fr^u^AyH7^7^r7ri, zlx 

fOHand leMes s age^V 7h^WtBto 
1 6 . -rCO^ 'y^-iSZ&m-r&tztbtZ&bh.tim d 
t_TI nStreamHandl e^/y'x^h^l 
mZtlX^&i%& csm_Receive 
Process: :Receive () Izttf hW\<W% 

&uz£^xm%mzixx^tzM&) . *tv»iM>v 

[0 26 1 ] wC^MDTcO^tCctoT, Tt'JXhk 



(81 ) 



*tga¥ 10-207751 



^(Cct 0. jl— y 140 5(Cj;oT^X^^-fX$iX7t 
3 *»fco^T*<0 h »J #*fr£50H&W:?-x *y ? 

£\ *;h.«iJfcfc^fcltfr*-4 . InfoFrame™ 
llffllOT^ U x h £H?r3-& fcftCtt 3 £ k WT* . BB 
att«t 6*tfc InfoFrame™ £fft£-T& «I fc # 

*. T^>JXb0!)ffi«i3j:tf I nfoFrameTMiO 
MS*AT. MDTO»ffi«i. r MDTOMe tad 
ataTM25j fcDMix— ^ • 9x7Ai>^TMD 

[0262] rMetadataTMj t^jfju- 

(Hi ) o+^#ao ^-^(ck-t^x-^j 

fcU? . MDTOMe tadata™ 2 5(i-?-C0x— 

#X^V>fXHri£^t^-£$t^&. MDTOMet 
a d a t a™ 2 5i±—mc07—7>l/t LXf—? • 

xr^X2 4<04HeMe tadata™ 2 5£*I#> 

lo^iS^Tftf), *UMDTTHS-XM/ 
• ^iTA*)^ 2 4^3£cOftIf££{£oT 
MD TOM etadata™ £t£3ILT*£j§'r& CI 

[0263] MDTCDMe tadata™ CCfl±5il 
Sa*4o*&. ZiXh\t ( 1 ) f^y^a^^I 
tt. (2)Wy^J:^-f^3>', (3) ffl 

. ( 4 ) ffigggnanft-cft * • *«woti« 

li— jltfO-r— ^MzXiXZtl^tl&mmtnMe tad 

^x?h£5£igU *LTffiO#^AtiMDT<0Me t 
ad a t a™ t *>x7VWX<7)Pgf&X3r-- ^h^SO 
»7 *y tT>^£*§flM-* . #t— ^7K?>- tt 



[0 264] MDTcOM etadata™ 2 5*1. g£ 

t — $ m&im^®M£ t v^9»wsr 

m&tittt. Ztlblt (enumerate 

d ) coittj tmxti*. mm. *»wi«t r « 

( S t a t e ) j litt*>*ffite£RJg3*t.& 

#B<7)5 0<7)##L *<0t-? • ^iTA^^'i: 

MDTOMetadataTM^f-^ 
11. fiESWtc. V-x ■ n-K<D^y^- ^r-OUO* 
T5HfflT*S*t4«[^Mfc**art-. r e num]fcv* 
5 Btt w O^ ■< 7<M] ? Atom&l&t. 
[0 26 5] MDTtOM etadata™ 2 5«Of" 
^/U«3Rtt4-«H5t:. ±^®SC0*M etadata 

il^MetadataTM^ tS.klMXXh 
l^— 3 >^f(rM etadata™ ^f-^J:!^ 

-SBBttO^-r^ 'J (vocabulary)tfc 

^yyaviaft, v-t7h, tixxmta (man 

T*4) T*0»*. ^-T^^V^HVUl-ffiOJStt 

[0266] ZC0-t7i/ a ^t^t^TOf-/;Wi 

f )i7Ar)x24 comma J: t/f^Of- ^ <7) tf jl 

*OifO^-^i>. — *(cxvH • ^-if^^M-rS 
Clk«lT^^^ e ^/it. MDT7H$-XM/-^(: 
ioTMDTfiOMet adata™ SrSt5RT&3C:a'!>. 

1 1 je» l t fc * if § soE^ifiss t % h «r»tt*« Jb & . 

I diiffeOx-T'/Uk i OXS^WC^^-r^^tc 
ffit>ix-S>. Seg-I (HtZcOf^^y^aXOb^y 
K;^-t:^>>hC0I dT'ftO. Commentlia 

[0267] 



(82) 
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7 2 5 6 
jDInld 

mm 




Seg-Id 


C omme n t 


0 0 1 








0 0 2 

















[0 2 68] »:£Ogii#f>f ^^v-aXC^hT^f^T htltz-T 4 X 

Oltt^Uv^. #Stt<^--^^rI d (At Zt&X'Zh 

tr-Id), &£Xf*:tit>tfm,LX\^^ j * li. #1*8! ( 

VyaVCOID (Dim- I d) felTf*. HSr&x-f S(f loa 

^V^3>t3^^JSttc7)^B5(^tr*>oTJ:^ (L e d - i n t 

*»U <£*l^OI D(i^=5roTV^) . MDT-Typ icted- 

e«-f^JKtt^OMDT^>fr*^. #Jgtt«i#a^-r **• Co 1 

T — — XCO$*<7)y 4 — K (Col umn-Typ 

e ) cO+^^-r-zWHcT)^-^ - 9 A rSr«F*ftr*. [0269] 

Dim-I d7 -^K^ttoT;<Of-^fe4i 



V(c^^"T^T^Stt$r»ai"r€» 
. MDT-Typet:jttt§enuml 
e n u m ) v (int) , &tt'NKj& 
t ) . BJRSixfcSaR (restrict 
) . »JH3*l£i»'J«U» ( r e s t r 
float). (string)t 
umn — Type tiZffii'h e n u mfiMr?" 



Attr-Id 


Nane 


Dim Id 

(f ^> 
y>©Id 
(&&> 


MDT Type 


Table 
(t-7* A) 


Co 1 uun 

WD 


Coluan 
Type 

(^J4PM) 


Comment 


006 


nmm 


001 


eoun 










016 




001 


int 










0057 


»J-y 3> 


002 


eniuo 










017 




001 


enuD 










0095 




002 


float 












... 















[0270] W*ffltf5KttKWLT*0««i<li5>0* 

f^ttffl^ j & tF*fc «fctf r Dept — 01 
7j ^fc'c^jW^'r— ^«ttO*fr^H***tr. ^ix£> 



t -D i s t i nct-j 7xy-teioT»4»W;:ft5 

[027 1] 



(83) SfBH 1 10-207751 



At tr - Id 
(S&I d) 

i 


Display-Kane 


DataNaae 


0 0 17 




Dept*0i7 


0 0 17 






0 0 17 






0 0 5 7 








... 


i 



mzmmTfr&miHZ rft^ffl j Sr^-fS . f<OM [0273] 



J 

Attr-Id 

OBtt I d) 


■ 

Mi n 


Max 




0 


12 0 









[0274] &m'\-^*mm<7)94-T<r>m'&<7>m&. a: ^^JSft<oKHfcj:^afi*>*g^<ST-^v^^, 

$fl«.^(=fi!f(lT-J)S^{c rft^Ij £5£i§-f l>. -5" [0275] 



I 

Attr-Id 
(Sft I d) 
(*»> 


M i n 


Max 




0 


1 0 0 0. 0 0 









(84) 
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[0277] vh^iix-en^^o— 



<04n:*SgS£fU>o «Ui££ftJ:iflft^Jjre r AL 

Xii^x^^VS/3 V<04fl5T*£. Num-Att 

hjTtt. Num-Attrsii0l:fl<«. 
[0278] 



1 

Seg-Id 
<t9'*>Hd) 


Dim- Id 
(f*^»3>Id) 
(&&) 


Name 
(45 tt) 

(*^*j> 


Owner 

Gt4=*l> 


Num-Att rs 
(£#) 


Comic ill 


1 1 2 


0 0 1 




ALL 






2 6 


0 0 1 




ALL 






1 4 


0 0 1 




pes 




1 


117 


0 0 1 




p g s 




j 















[0279] iknmiwnmmisffiggdxs&bztix^ 

-To ±Mttm$)<?>'fs<OipX\ Attr-Id 0 173^ 

<=1 0 0 j ZTsk-tZbttZ. ^x^' 
0<£9±£<. *LT1 0 0 J:>5'h3**j T*>&. mVi 



& • Operator-1 ( jRff?- D^enum 
Iligreater than (i:0^V^ x les 
s than (J; V0 „ greater or 
i s <A9*&^*»4Jttt*U*> . less tha 
nor is <J:9'h3v^4fcti*U*) . i s 

(fl^) .is not (SSK*:^) .is be 
tween ( Hfc* -5 ) "Cft * . 

[0280] 



(85) 



0-20775 1 



Seg-Id 

(tr 


At tr Id 

m&] d) 


Value 1 


Operator- 1 
(emio) 
1 ) 


Value-2 


1 1 2 


0 17 


0 


fbetveenj 


10 0 


1 1 2 


0 18 








1 4 










117 





















[02813 ymmt^r*?* >Ynznthnm^M 

Name (^-?«) J ^ A<«5fc R fCft* . M 



h-rfztblZh&o Z b ifiTZ & * OperatorCS 
t-Se numlll i s (TS>£>> .is not (t 
SrW , isin 1 i s t ( «J^hW:*S) . no 
t in 1 i s t ( 'jXh^V^) X'$>&. 
[0282] 



Seg Id 
(tr i>YW 

mm 

1 1 2 



At tr- Id 
(JSttI d) 

0 19 



Operator 
(en um) 
Tin tistj 



Data Name 
Seattle 



112 



1 4 



117 



T 



Ptrn-Id 



Name 



t±3-—fl 4 0 5lcJ;oTJg^$ix&^^#&&. 
[0284 ] 



Owner 



Attrld 



(86) 
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(A*-f-f*>3>Id) 








5 9 




ALL 


0 0 5 9 


1 1 7 




P g s 


0 0 17 











[02853 ac^afci^^ijc^aw-fe^vh/^^ 

co^'-x 4 */ 3 £*ufcy*- 



[0286] 



Seg - Id 
■fc^> > h I d) 


Prtn-Id 
(/t— 5=-^ > I d) 


112 


5 9 


1 3 


117 




1 



[0287] iJOT*i#^--r a >1,zfttZ>1 L -t7' 



[02883 



P r t n - Id 
U\—"r4 ya>Id) 


Seg- Id 
(•fe^^>h I d) 


1 9 


1 5 


2 2 1 


2 2 2 







[0289] m&.mmi j f-?iz'?^xM%x'Z s-f- 



fc il^*7 AfTvrtS. Display Unit 
*7A«I nfoFraraeTM^|j(o 
t>0-C*S . Precision (IftK) »i 
4«j*W&l«fc:«fi}lKr«3»T** . Ro 1 1 up (o- 
/l/T-yT) izftt h e n u m<I(i a d d (SdSl) . av 



(87) 
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e r age . count (ti^yb) X'hh, 



[0290] 



1 

m id 


Name 

OfcilHl) 


Rollup 


Table 
(t-7* %) 


Coluan 


Display 
un its 


Pre 

c i s i od 


Conaent 




(£3=#l) 


1 (eoun) 




(XI^J) 


(5£^1&&) 


<&&) 
(g&) 


(X^J) 


055 




add 












0917 




average 





























[02 9 1 3 S*<0«I5£JSS . fcSScO-JIfcilf J|DI 

2 s v b • -fe^O< v h . yt— r -r zs h y<o-T-fe^ y h . 

«RM-Sfctf>fc 1 SO-b^ y h ^^^T^-i: 

Left-Arg (&<03I8C) <fct/R i ght 
-Arg (*<ogi») ttiifc^S*LTV^J:-5C r L 
e f t-M (£^)M) j ifcfcfc rRi ght-M <£-<D 

i . m^m^mm 

2. 



3. r^_y> y h . -fe^OOhj 

4. rja-fc^oo-h j 

5. -fc^OO-h ■ yxh : 2d<og|R(iS 1 i s t<0-f 

6. StSb-kfXyb 
7. 

[0292] O pCOtpcomg-^F&gJgMM-? r c o u n 
t (^M .sum (£U-) . average 
*3> jtl.^ Le f t-Mfc*«t3&««*)*l*. Op 

o^^aww-^iaijr?- (-k -«r*r> -e&6%£ 

fcL Left - itXR i g h t - M^Mihfl 
*. 

[0293] 



i 

CM- Id 


Owner 


Name 


Display 
Unit 


Left 
-M 


Left 
-Arg 

type 
(£<H 

) 

(enum) 


Op 

(enum) 
(@&) 


Right 
M 


Right 
-Arg 
type 
(*J« 

(enum) 

























































[ o 2 9 4 ] tt&a&Kg*'* ^ >- h co y x b zm- 
§£\ *<nvxb^mi<k0>mrcm*>ztLi>. 

[0 2 9 5] 



(88) 
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CM - Id 


Seg - Id 

<fi&> 


1 7 


5 


1 7 


1 

6 



[0296] fteymifi ^yya^^x'J-r^ 

fc»LT. ^il^c^^x-^/USrtS^ (join) 
[0297] 



Attr-Id 
(■ttl d) 


BM Id 

(mm 


Attr-Coloi 


BM - Co loan 
(BM^7i.) 


5 


8 


Tcust_agej 


fmkt_sharej 











[0 2 98] &<Z)»ix4*>s'H>Wtt^y — £W 

&. -t**?^. mcom (±ib) 3&«*^affi3aafc:»i-4 



[0299] 



1 

| Attrl-Id 
(Sft) 


Attr2Id 
(Jg-ft2<DId> 

mm 


At trl -Colurn 
(JK1£ 1 <Dtn) 


Attr2 -Column 
(JRtt 2 <D%7h) 


17 


4 


Tcust_agej 


Tagej 











[0300} mfcmmi3commiMjmmfsi*>m&m® 



[03011 ft^ias&rogBiis^Mfli&ttaj: 

5 CC^IS^- & . I -Direction (I CO^T 

1*0) Ji'vy^- y T 4 WPiZfemZtlZ^Z 1^><W\ 
1$m<7> fdirect (JEfifo) j 4fcl± ^inver 
se <j£fr|6]> j *Hvf*ij&>T*6. f<Oi*«rdi r 
e c t j *Olk&W@Hg4<JJM-& 

«imji^JlS* { ±#-r-S.STA€.. {-Dttftf r i n 
v e r s e j T*-5 7tifrS\ *«>lfc&ffl@lIB4 t .hJW 



(89) 
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c t i o n e n u mffiii d i r e c t ( JE2if 



|»G), inverse (j£2»ffi]) TJ>&. 
[0302] 



T 



MR- Id 


Owner 


Independent 


I Di rec 1 1 on 


Dependent 






Mid 


(I -2rfa> 


Mid 








(enum) 




<&W 




JIB<Z)Id) 




jse^id) 






<&w 




(£W 


019 


PGS 


5 


Tdirectj 


21 













= . = „ not = v ^.fvltib e twe e n X'h h <> be 
twee ntf)ifr£\ Value 1 (ID iValue 
2 (ffi2) £OM;fr#&;Mx£u Htmenum 
ffiid. is less than (iOW^) , is 
greater than (i 1 )^!^) , is le 



ss than or = (i^l^V^lift 
^) 4 is greater than (i 1 )*!^* 1 
SfcUSfUO . i s (*L^) .is not (*£L 
<^TV^) % between (SCJ>^>) . not be 
twe e n (Ht-^^) X'$>&. 
[0304 ] 



MR Id 

(&W 


Operation 
(enum) 


Valuel 

mi) 
jaw 


1 

VaIue-2 

j**w 


019 


Tbelweenj 


5 


100 











L 



_L 



[0305] &.cr>mi$m#m<?>T-i-v * b%.mtt£<?> 
s <o*ais£>i m fs<?>m&tfmm s i o (stmt %> . 



direction ( ~fifi>[ ) <Ti e n u mfiHi , i n c r 
eases (t&/jU"3 & ) , decreases (jSiJ^ 
£ ) -eS>& . 
[0306] 



(90) 
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I 

MR Id 


derectioo 
(eoun) 


Value 


Unit 



















[0307] yant&±*rx v f rt (cai5&SBfa«oRi 

[0 3 08] 



MR- Id 

W3£*@IH«>IW«<OId) 

. 


Segld 
<iryj*> Hd> 


055 


19 







[0 3 09] ( a ) SffaJJiM D TCOM etadata 
™ 2 5<0 1 o<A*5»«#"C*i . 1 

SHS£LTV*&. Base Unit lc*f 
-f &e numltl day ( H) . we e k (21) . m 
onth(fl),year(« 
[03 10] 



Base Un i t 
( e n u m) 



Day 



[0311] -x^— yjutfmfemmzx o 

[03 12] 



Table 


BU-Id 

(S*iHJ£JSgtz>ld) 


Colunn 






9<h-irsT 















[0313] <Jc«03M±JL-if 1 4 0 5fc»LT*9?T* 
&-5If£tt<7)J>6. *0**&*iESr^il"r&, Week 
Start Day (5B0>BHteB ) e n u m 

«H±. Sunday ( BBIB ) . Monday (/ilg 
B) . Tuesday (ikMU) Saturday 

(±BBB) T**. 

[03 14] 



(91 ) 



SJgfHPl 0-20775 1 



Name 


Start Month 


Start Day 

mm 


Week Start Day 
(enun) 


Comeo t 

cm) 
(*3=#i) 


Calendar 

(%v>r-) 


January 
(1 R) 








Fiscal 


May 

(5/3) 









[03 15] 



[0 3 16] 



Jan 


Feb 


Mar 


Apr 


May 


Jun 


July 


Aug 


Sept 


Oct 


Nov 


Dec 


Start 


Start 


Start 


Start 


Start 


Start 


Start 


Start 


Start 


Start 


Start 


Start 


IB 


2Ji 


3J! 


4* 


5J 


6fl 


7fl 




9a 


10JJ 


m 


128 


ate 


Eft 




Ate 


Ste 


Mi 


BS 




Rte 


a* 


Bte 




(tt) 


(It) 


oat) 


(IS) 


(tt) 


(150 


(ISO 




<!*) 


(Si) 


dS) 


(lit) 



















































Quarter 


Quarter 


Quarter 


Quarter 


Quarter 


Quarter 


Quarter 


Quarter 


1 


1 


2 


2 


3 


3 


4 


4 


Begin 


Begin 


Begin 


Begin 


Begin 


Begin 


Begin 


Begin 


Month 


Day 


Month 


Day 


Month 


Day 


Month 


Day 


GIB*! 




mm 




<X3Bf| 


(fi3Bin 




am* 


mm 


onb) 






AIM) 






CDlteB) 




(5$) 


(St) 


(5*) 


(») 


<sa) 


(tt) 


(tt) 



































[0 3 17] y'jT^DAI (S-DAI ) 14A (0 
26) li^7>fryhl 2(C*fLTMDT<OMe t a 
data^ 2 5\ t ZMthT9*A*m®&&Zt*]g. 



hO-b^s/gVtefflKSft*. JBWRSWrfcf^), Met 
ad a t a™ 7V hS^liy 

'JT^ODAI 1 4 A£<fcoT«lS$il&. SfetC* * 
<7)S — DA I 14AliMDT7F$-XM/^t:Sf 



(92) 
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[0 3 18] i/VTtl-DA I OT-^rf;ft-^02 
7(3^$ilTl^. x'JTVPDAI \ 
h 1 2*^MDT^ ^4r-y^»E«eTK*«:S«tKS. 
#MDT^ "/-fe— i^iiS — D A I 14A?>+l;:-HlS# 
<O r tf^?^Xj $rftoTV^. Metadata™ 
cor^-bXi>J;^#^SBBT^*6^ -y-tr-^iD S 
Ml 6<OMe tadata™ t 1 — * 4 ^-7i 
-X£MtT«Ui3*t& ("f Classic^ 

teC 1 ass i c^^-^M4AA^tf 

[0319] Metadat a™ <7>T ^-trXfc it^m 
HirSeSrW— b'XJiC lass i ccoav^— *>-b 
UAAtttfcflC. j/'JTrt'DAI UACioO 

wryM2c»LTa«8ftj. ^^>fr>-hi2 

*^OM etadata™ t^tUt 

^7^TyM2^^7-fe-^S-DAI 
14A(~*tLT3&frf&. S-DAI 14A(a«)«rM 
etadata™ :/^2 5(cr?**l/C3BflJ 

5:Metadata™$:iaJt5.^ «lSr'*-y 
^r-^tLT 1 0*fcl«ftELhtf>;< *y -fe-i^^ClA 
tt*C^7-f T>hl 2£»LT5B*-. Metadata 
™^>f y^-7x-Xiiv^yy 7 ;OMet a d a t 
a T M teXZ/Z <r>1&fecr>i_-*f\ l zftth M e t a d a t 

[0320] x-^^ J: VWJfB<?>HRW*8Wx^ 2 8 

• rxf7r2101j^7^ryM2^'Metad 
ataTMtfJBJ^ >y-b— >-*£S-DA I 14AA(C2* 

• Xf772 1 0 2 j i^'JTyl/DA I 1 4 A(3-£?);* y 
-fe— ^* • 5^ TfcW^ if^)M etadata™ 

• rxf7/2 10 3 j ^a*7^-^|oT, S- 
D A I MtjELl^M etadata™ SJfttMe t a 
data™ "f—7)V2 5£^E^M> 0 

- rxf7r2 1 04 j S^JT/UODA I 14Ali^ 
Metadata™^ ^zj^-^^ 

• rxf7r2105j y'J7/^DAI 14AlilO 
OMetadat a™ p< y-b— T>- h 1 2 

[0321] TOfittfcfcJwfiri^ X7-o>f<yb« 

£U£S£\ S-DAI 14Aiit-A^X7-- 



vhi23^fe«fu«-&ateaa3waans*i6. ^:x- 

fc. yyT^DA Itt*tf5lS«ISrl9ie<7««j5SrMe t a 
data™ T--^K^LTiEJirt^o 
[0322] Sl^g h';U^®ffi^+T'fBlS^)S!^iS@ 
Sr^/I/T^TU U *LTSavc (ft 

^SS^a^I d^otMetadata™f- 
:TA^2 5i£»LT«ffSixS. ;^7VM2lfcL 
-if 1 4 0 5WI»i^ 7-fe-y^LTCc7)ffl 

iUm<7) I nf oFrame™ W:^Wei^ 

4 o s^m^tt. zeM&m&mmwztitiwT+v 

oFrameTM{i]EL<M^f, rrt'JXh- 

[0323] *rU«^BRto^£»ill*&£ k 
tt. •rLo«^®BBtiftBlrt-6^kSlittLT^*. 

t^Wi7; (i^)ii^7-iryM2^ 

T'^-T^o ?^>fT>h^\ *L^ffl^BISkoKlfiR 
^^ftSnJtCfc^-tk, y'J7;UDAI 14Alif 
cOttfBSrlS^OM etadata™ -r— ^WCiliir*- 
*. «^BB*0BB«*SESE'r*C:ktt«*T*4. tt 

*>I daMMmt*. a®BBiaoBMR(±*ii*«i-ir 

1 4 0 5^«toTm*SnT^**&t:ffJI*"r&wi:3&< 
*<^a^BI^Riai3j:l/*^0x-r;^x 

2/3&«ji--iP*c»LTII*3fL. i^OWgaBHoHflW 
T^'JxhK:J:oTtt*xHTi>6*^. «ua*tf> I n 
foFrameTM|igrtf 4 -£LT rrt»JXh • 
^>fAj eox9-36%4-r&ik«r»»-r&. 
[0 3 24] &tz. is*JT)UDA I HAIiMDTTF 

etadata™ C^&l**<0CT£tTdfc«>fc:fifc 
y'JT^DA I 1 4AliT-* ■ ^iTA*)^ 
24K^5>f7>'M 2 (<r-* * »)i7A')XOX 
*-vflMR*5 J:tf M etadata™ OPTfrfciSflL 
TV*&> T>-h 1 2j&»fe<r 

■ *>x7Vv>X2 4^<7)ff$8 (^^CliMe t 
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adataTM LTW*) (VfttlZtmLWftltf 
3r4>&vn xUTVUDAI 1 4 Ali-r-^OfcOtco 

*u ^^rybnm^SRt^. mot**? 

h T v 7fo& V*tt-f I ZtztbCDAT y TtfS 

ArvThh. #^T77li^7^7>M 2#T 

iitTSftKO. fPB£S-DAI l4AfcttLT8W- 
ItCiMI.. S-DAI 14A(j:DSM>f^-7 
x-^$:IUMet adata^ c9x-:/;P£H0r 

1. t^V'S' a 

2. -r-^^-^tO*5A(c»LT«ttSrffiaiL. *L 

3 . «F#fcSix*:«5W«: U 

7. ^-f^-xnx^j^z&mcD^-xtLzmo^ 

[0 3 26] WtcK^S^T^SioK:. JL-if^-fe^ 
as s i c<7)3y^-^yh HAA^'S^, jl— 

ftfio^-t^yhtuii, sag. ttzimm-f&t 

C l a s s i ci03>^— ^yh 1 4 AAli^OH: 

4 yf — y^—X&Xirzco^W&ZcM e t ad a t a 

• 7 /2 2 0 1 j 7> h 1 2i^^yh 

• r^f7r22 0 2 j S-DAIti^oS^SfTT 

• r^f 772 2 0 3 j StCS-DA I liC 1 a s s i 

C 1 as s i ctftoT^WfcioTWISftS* 

^ > h/;\*-x 4^3 VcoSSco-T^T SrifcTT & . 

etadata^w CO^r— ^;P*SSE*-f TV 



- rxf772 2 0 5 j X7-#&rt>o*:*£\ 
cO^IE^Me tadata™ <7)t-— . 

• r^f772 2 0 6 j JrSztzlf. ^v-tftcti^tzh 

- r^f 772 2 0 7 j 

[0327] JL— If <0*r ^OO- F OK/Iti^ — ' <<0-r * 

Cilti-fix^Me tadata™ ^f-7^^ 

*»&T*4. «-r-f ^>^3>fcJ:^«-^-"-1ftc«LT 
l^coaHS<-X ■ 7t^^»6. Z-yr^MZV-- 

ion. u s e r j &tir£$ilT^&. 
[0328] JL-if 1 4 0 5UJBt#«0-fe$O< >h (^f 
h< h77 • l/^/KOt^^h) £H«WS<Ifc(cJ: 

6. [^SS>6 5. 1RA>1 00K] ^jgttfcJrltfPJRR 
(We a lthy Sen i or s) j «T 

[3 0 29] ^Xcomg 

[By-Age (^ftglj) ] <--e^Sttt-ctoT# 

^m> 6 5 o e»w(wA*s<xfc+ia-fe^> > f 

[By-I ncome (JRAJSU) ] 
*:xF 

[0330] m&*>mmmiistzM3Pcb& . 

MUr^O^h r*SaB:^E*j (iiRA(cJ:oT. 

>-F^J:^2o^i ift mz&OL Ztifz'^r- 4 is 3 v« 

r B y — I ncome (JR7J3Q) J T*9. +BHr^-X 
>h« r iRA>l 00 j ttc*). *LT»2Wt-x-f 
^3>(i r^jj|j > . 

[033 1 ] iJCtfD^ K7>f >-^*rLV^-t=^>>hco^ 
mzftLXV-tf-hZtih. 

1. a^JL-ifft^SWr^Vha^feScSii* 

2. r^-^f— h LTV^&j ^N*-x>f s^3^*>J:tX-fe^ 

1 4 0 5 1: J: oTMS WSitt^Wf TOAffM 
6. 

3 . g»Hr^ v h #BRW>if x -f y 3 > 
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#lo£j£$ix&. 
[0 3 3 2] -f<XcDm& 

crash 

BiRA 

[0333] *<0:z.-lWi±B4> J: 3 £ r *S*§2r^K 
#j taw*. *^WWic:i'Wi*oj:3fc:Ai 
6. 

[0 3 34] COBS 

[«A8fl] 

[1R7JM] 
+fUg<?)iKA 
itiKA 

[0 3 3 5] ZL-if 140 5ifimL^*?Xy 

yh<oTizmLX^h«mo^j<yhffi3f>i>^. * 

y -f >- a y<WBmi*WG#*t>0>Tbh. 

frtm^cof m yi/ s yizlftZ rh^7-K/uco-fe 

-Xj SSTSi&T**. ^zx-xizf myi/B y 

x\ m&<nfflm?)%:\<^y*yhX'$>&* i*tiw r A 
ll-xj zzTxum&ttiim 

o^ho^n— f--f va^Srflli'CV^. -r * f> 3 

£> * 1 o<7V \— t* >f Vtifcfc* 1 o^Offl-fe ^ >- h £ 
[0336] JL— y 1 4 0 5«B»frfe^^h4fciaB 

1 -c* & 1 1 * 



[0 3 37] ^Oli-b^VhOiliU (— «ktt**fc 
^^^^>locoStt$rj|S/i(WSoT^-St 

iiSD£ix& (#»S#^-2 301). 7^7b L,*a»ojfc 

302) 6 *r^T^frLvv\— r-^^3>-^<t3tc. ffil 

^>h<^flS<0^-^TC0» (C 1 a s s i c <&&&\*t 
^X&tfgL) ftfMMc^Lv^^ y h kW 5 1 o 

#^-2 3 0 3lZ&W&mz&\vXf&frth X olz^ .Wi 
fctfB1W/t-f ^3>( #SHH§- 2 3 0 4) tcif L 

S^230 5(C^Jt*fflU2olU±^JStt^itS ; 3rS< > 
Ztil±ft&LX^h*7*yh<OW¥£tob&^Zh{: 

*<7a5U^W>b<W:/-?<yh (#Ra#^-2 3 0 
6£0i:d^r) (C 1 ass i c^(iW> W 

#-^-2 3 0 7 co J: 3=flrBIBSW^— -r -f 5^ 3 ^tc^ -f v b 

Classic 14AA*««Wl6^ in 

A^3: JH-fe^VbiJit/WLV^-b^Vh (NE 
w) . frL^^^^hiim^mttSJIS^^n^n/c 
fe^fe«fiKS*i&. 1 4 0 5A*2oJa±<0«4 

I/aiSix. *<0+iaco-b^>-ht*tLT*«r*«f^*3 

[033 9] NEWCC^LT— BSWSrC lassic<7) 
■fe^>>h$:^T*, NEW3&«H#^>-b^VhtH 

jcy 
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* / 

r N E Wcoa-b^ > h j 

for*S { 

i f r^/<;m== i j { 

f its_l fag = F A L S E ; 
f o rZCD^jOhW&^r^— *r < Is a V < 
I f f O-fe^ > h^OA'-f ^ y 3 >f^i:7 J y h*th) 
f i t s_f 1 a g = TRUE ; 

> 

> 

i f ( ! f i t s_f lag) { 

f o raft^^flS^^TO^F < 
i f r ^^^^^frtWN'-f-^ i^a j 7 Wj 

) 

i 

) 

» 

-en^et^^-x a ^ a >cm lt sin-*- & a\ *> * i 

* / 

For#f { 
i f ru^OHI== 1 { 
for N E VfCO&^S*— <f -f i" a V { 
i f Hfirt-*r Jiosyizyj <y h-f & { 

f i t s_f 1 a g=TRUE 

) 

e 1 s e { 
> 

> 

lett****. ^ix^ma^-fe^^h^ffl^ti^^c [2401] to^-b^^hou^&noBK 

«4»I^+fcM0»WI^^ [2402] A^>-tE^>^hab%V^K^. *W«-x-f 

**«Hii»sft.s«eai36«aj>*. [24 04] fnww^f^aycsffi^^ 

[0 34 1 ] 03 1 Sr#ggLT : vbUt^j *»4r3*»MK*. 
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[2406] ^co-fe^ > r < is 3 VCO'J V ? 

[2407] w;t-f -f a ^ SHTO-rs 
[2408] *0>=Hz7X > htf>'J 

[2409] ttib&m/v-T < * 3 >ifi*\y*Mt. m 
[2410] %<n*:7* > h iwmth 

[0342] M&^—t Jiss 
coj -fe/^yh (d^Tii ros j tmftiX^Z) 

[0 34 3] ^Tfl** 

^>6 5 
[JRASO] 

[0 344 3 ^-tm^hV rjRTjgfjj COTCOOS&6 

y- h -r* £ t tz i ^xtm-t h z t it-?* h . 

[034 53 JL-i^ 1405 tfgf&Jlcu^ yt&m. 

*>iC*5V^T. C 1 as s i c^SfflK— j^tt*HW5rM 
etadata™ ^-^;P2 5*^»^t:$*V5rWl 

^ > h*5 it//*— r ^ >- 3 >-£Sy*co$fff§3K-x L 

firT'££. (DClassicl4AAW§Ig 
<0B¥aiL£tT^<r £tci^T. (2)Classicl 
4AA#Htf«Ii:0*T§4ASC I I<075*y h ■ 77 

*fc:*Wr*6^TIBtta& f **. Classi ccO&tiK 

[0346] ■ if^yygVCTU.f^y 



^3 yo£if- ?Vua»fcK*ai-*\ 

o r^f^r 7 o-j^«n 

O ^T<omffiHIR3ng£ft& 
=> W^-f^ ^3 >fcr*tLT 

o 1 ^comm^-T- * is * 

j&flirf ^:fci:J:-ot77ey^ & 

;\'— f -fyay^W^ yh^t^TOT-y 

ey/cj^u 

O i»A e -f^ >-3 Vt^LTii^JcO-tr^^hSr 

ilirr & ;ti:J:oT77 ty/^iSts 

[03473 MDTcDtTi^X • U-^UOJL-if J3 J;tX 

OJL— «f ) O^fKJ: ^Metadata™ O&hL 
fflfe. iJiWWKSat) t*A/CV*4* Me tad a 

taTM (OtfjE^-o^TJUTfcrBlW"*, Metada 

h. lO^)HSeBBt:*>V^T«±. y'J7^DAI14A 

h^ii^3S^^^g. ^=Sri5*>. ajn. fifl^. *5iV 
. **LfcI*^*>S MetadataTM ^ 

B^RH*S:*^*t^. MetadataTM ^^JE-T 

r ^ »j ^ h * i/^^oa- rco 2 o . -eoM^r 

SlOXf^TliMDTAh LT«ffl3<lS. MDT 
AtiJVXV 7«Metadata™ ZmfbtiSlfo 
^-^tLX^Lhi\h<r>fi*¥mX'fohtf. *"TLt>» 

OW^^MDTcOffecO^aOM etadata 1 " 
*30E^*MDTAt:ov^TJ4HBttfe:«±»i«rv^ Jfc 

[03483 
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a— *f 
MDTA 


urn 




MDTA 


jinn 
MB 





[03493 Metadata™ cofgjEii-b^O* > h 

mMKcmtl&?7JT>hl 2Ky'J7;PDA I (S 
-DAI) 14A^ -fe^pO-H^W^LTV^^ii 
C 1 a s s i c£0ny^"^yhl4AAA. % -£LTtf: 
(,ZM etadata™ cr>7~—7)l>2 5^cr>mtlT$> 

[0350] Metadata™ coBJEte 2rXDW& 
COttMzmimiZ%:&. farm 1C, Metadata 

T *<7)mzm^ii&i?&tz>. mttf. im&^y^s 

ficfftt. hh\,MZMDTAI,Z£r>X f gmZtlX^& ^A* 
yj7^j Metadata™^ #S^0^-— -^O^* 
7>f<-hMe tadataTW ^^HcOfi^ttTj) 

ad at a.? ™ lZttLXmm*&-*Jt%&&$>&. 
if. 

[03 5 1 3 1. XiUt^Metadat 
a T m ^ -T^r^^ fflBfc£fl*;Me t a d a t a T M (C 
MLXTi-V^b tftifl. BSC: £f A,2r <I t h 
? 

2. Metadata™^iJi$tL, flfiOMe t a 
d a t aT m &Ziii:0m~t&mzt'A,%Z t h 

3. MDTA3^a7U7; ■ -tr200h£^-r& 

4. MDTA^'f^^H^ Stt. £*:teS*88 
[03523 ««0«H*c*SOT 2oc0ffi^S:;*&£S 



9 WUD r^L-ifa^j «3fiv*J: oizl£Mt*hZ tip 

co^h s fr«c lx . mmxz h mm-—? 1405c 

-if 1 4 0 5 im?* i 33r<r t li«fc LSrv^J; 3 irT 

[0353] 3^1/yhDAI (CDAI) 14B 
(02 6) lilnfoFrameTM tMt*MDT 

• t/y^fA 1 8*>>£><Z> I n f o F 

rame T "Bare*o. *#i«oaj*«iJL— y<?5U 

Lt^-X h ■ Utf- h £*X/CV*4 1 ^><0 I n f o F r 

ame T m x*hh« zixtfznxoizmmtzixx^h 

[0 3 54 3 CDAI HBiiUNIX™ 4/^iiNT 
£0t»A' • 77 7 h 7 t-^itl^LTV^, UNI 

mdtqueryengine [ — c<conf ig 
>] [-e<e r r 1 o g>] 
ZZXc o n f i s&&*Ve r r 1 o g*t«-*ve 
*U vx9W%tLiWXfft*^{zvA?(Qav>'Yffl!>* 
A^v^*rlzJ:^XMMZtitz. *yisB>cr>zi 

[03553CDAIC014 B«|g(7)SK&»a«3^7 

£A^T«5e^&«r £*t 

^>-*=SriT«3»*-6L*v^lSr»5&r*. CDAI 
1 4B«JL-if(cStt^ I nfoFrameTM^ 
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fc-«i*V>TOl3W&6. C«14ts CDAI 14B 

-fy^^D^iil nfoFrame™ iC^tt&n— 

• 5>f XSix^r^^rX h icStTS V-X £ LTflfcMi 

[0 3 5 6] fttfLZtltzI nfoFrameTMOf^ 
hi 2t,z£-?xm&;Ztlhi)\ *6V*Metadat 

CDAI 14Blin>7^al--ya>- 77>f 
;WC*4ilTl^Ms gCa t a 1 ogPathltt^) 

m. T>btzx~?TmmztiTm i so 

MDT7^-^M/-^fiTOX7-- 

[03 57] CDAI 14B«ilOC0mdt_I nf o 
FrameReques t :* TVx 9 Y £ RU N_ AN 
A L Y S T_R E Q U E S T * y -fe— >?<D+(;:»? Aft 

I nfoFrame™ 
SrSSfiLTV^S* 1 n f o F r am e D e f i n i t i 

on (mdt InfoFrameDef init io 

n) Sr-athrfctf-CSS. **tf±I nf oFr ame 

[03 58] * r IM:(Summarizat io 
n) j -l-oa>9-¥ vb • ^^yhl^-fyh 

• r ^i&#fcf (Change Analysis) j- 
ttfc 

• $S5l*SBit$2 (Measure Compariso 
n) j - y-y h - -fe^OOM^OWCc^o 

• -tr^O*>hJt$£ ( S e gm e n t Compar is 
on) j -2oc7)S'J^^^— h --fe^VhJi-C^ 

• r hU>HM(Trend Analysis) j 
[0 3 5 9] ^SXUI nfoFrameTM Tri 



g g e r (mdt_Inf oFrameTrigge 

;v>X2 4J3±t/A 1 e rt75^tW<oW)ft 

fcj I nf oFrame™5*HKi:tfT'& 
4. *<7>K*3&«M;**Sr^TV^*&. CDAI 14 
B«4*«0ftfr*< ?3>il\il nfoFrame^ 

CDAI 14 Bti, A 1 e rt77^ r ^J 

6. — CDAI 14Bcoai^{in-^^>fXSix 
TSS5I$ix^HTIVILC0l/^-h$:^T*^$ I nf o 
Frame™^x^M:5ri (01 9#§H) . * 
CO I nfoFrame™«a-f • U*— V-XUT 

[0 3 60] jl— >j^-> • x»JTi±rJ>-7^^fj. 
l^— h > * 7T-I ;POU serReturnArea 
Pat h^7> — ^tCt-oT^^^ifeilST -f 

InfoFrameTM«EL<^7t4 
W^-MilNF. <UID>. <UNQ>t 
45ft*t^*l&. iitU I DttJL-1f I DtftO, UN 

[0 36 1 ] JLr.-^^MBJfHlT-f^^f-ir^CD 
A I 14BJ4*>±lf4^:f^ X^^y^CioTffe 
fLTlnfoFrameTMJBcJffiCD 

a i i4Btfi*tL%mmTZ&£oiz-t&, u^-hr 

^tcx- — ?=fc*«r;tefi«3:<7rC\ CDAI 14BCD-T 
yx^y^iiu^- h £ 1 o*fit Ljt>*?6±i-& - £ a*r 

§3rV\ InfoFrameTMS$tf2otU:^ 

-b^ast-****. **>s^£»twro**cDA 

I 1 4 BiiroM^^" h^Jait^^^Lo 

CDAI 1 4B^f * X^v?^ 
[0 36 2] iftfe^ftf^i^'TTVh - t:\x- 7 4c 
J;oT8£R£*l& e *«0VjK-M4I nfoFrame 
t m i/*— K T7—b • Ptf— hifcttx^- • U# 
— hW^ti^Sr-^tf. I nfoFrame™ W?— 
M4CDAI 14B*«I nf oFrame<05£f$£jEL 
<^LfctttCfft£$il&. **Uii f gn_Repo 
rt?7MZ£~>Tftf$.$tth. TJ-b • U*-M4 
I nfoFrameTM5^h«J^U^T, * 
CDbOXtf r^j IcfMBSfU A 1 ert77m-y 
h^;hX^&B5tCffr8;$*l& 0 f gn_Al e 

rtFrame^^XCiotM?^. • y 

U-^CDAI 14B36<hU^ifc«iI nfoFra 
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V>tZi>&tif1iZim*tl&. **U4 i f g n_E r r o r 
F r a m e 9 yMZ X -oXfttfLZtlh ♦ 
[0363] I n f oF r ame™ UtK— h (01 9 

[03 64] • r?—y<yh U#—hj 

#h<y:r • l^l^^X*^ FT* £B*UL ^co-fe^v- 
3V«4#4ix=firv*. 

■ f-v— hifctt'^ -^-v-K **t*l4«tfiS:*L 

-&J4. £<z>X?:7l4tfHfe*L3rV\ 
[03 6 5] • r y*?yi - fvju- • 



ii6* 5 ifOJ:d^a»«(c»63ii**»t»6W4, K 
U/l/ • ■ ;\*— r * ^3 y^S^dov^T^Tieo 
*?v3>£#ffi$ix*:v^ v 3 i/jWSPl&ir 

**V^I4Hift»t«ffO. 4fcl4£*8tifcAC— 

[0366] rHij;p-^y./77j -H'J;P-^ 

h*fc«4^-f K &^l4«r&l£SL/0>41B 

B KJM- v ^KfR«aM«^ L X v ^«L*iEP 

iicoS^H <**v*i. «0IBJ«ft»»fOfc«>O^- 
y-yM:tt«EaB©BBk^)BI^) Oj>9f#&JES£tE 

JSBH^Mft^X^fc^TVvfri^ 
[0367] r^-^j — t<7)»»ftf5BKc^-h3 
ix^-r^TOiH^lB^^^LTV^x-^U. SL * 
y h £ fc«4J«8<0-fe XX V h 7* y h fcfc^ 

I/. HI 9mm) . T«tt*^>HREF(4^- 

T^ffLc^r^yxhtcWLT. Pitao^SB. Jt8L 

[0 3 68] T^-h - U;K-H4^otfgJre&&. 
*<?MkfcW»»v^»tti4, 7+yxh*aftSM^ 
-UmftS. InfoFrameTMSJtfaiS 

or. jL-ifj4^^r^yxh*i:*>±«f&ci:^'C* 

[0369] 
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Alert: <7t'JXh«> 



[0370] x^- • u*- f«i *)mt&'Chh-*jffi& 



[0 37 1] 



X5- : <7t'JXhO 



[0 3 7 2] CD A I 1 4BliX7-^t-A'cOX7- 

[03 73] 4. DSMf^yXfAl 6*3j;t*X^r 

h. MDT^->^3 2iix— T14 0 5^LT<RC02 

[0374] * *«SSB:R ;Metadata™i07 
x7f, Me tadata™£0lSi, InfoFra 
me™mtyi-'Jy^. InfoFrame™ 

•^•yf-KR; h'J^lBWInfoFrame 



T lo^^ti^ixUUi0^xU-S:^t$-fr«»» ODB 
[0376] zs*J Tiwm$L& <£ 0 cottflWI f HJH 
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[03 7 7] Wi ndows NT T M ffiXUy F SrH 
<I t % * LT*3#CDU N I X T M <04?*^&frJK 

^t-Alfgwyt -y F * **i-P*l*SS LT v ^ 
[03 78] H3 2t«SW*k. *-^3 2liB«L 

• vx? • 7°cMrX2 5 1 lte-V—^tcOP'yJTyb 

• yjr;p- >fyx^y^2 5 l 2(i^o^^-r r>F 

(IMe t adat a™ <07x <y**3 itflESL Inf 
oFrame™ COX^jl — 'J V^K*$r ift* S . 
y'JT^- >fy^^yx(^^ya- /WSflfcl n f o 
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1. Title of Invention 

DATA MANAGEMENT SYSTEM 

2. Claims 

1. A database management system, characterized by: 

(1) a database comprising data entities having associated attributes, wherein the 
data entities are arranged in a first heirarchy, each level of the first heirarchy being 
associated with at least one attribute; 

(2) a server computer coupled to the database, wherein the server computer 
includes: 

(a) receiving means for receiving an attribute restriction value for restricting a 
selected attribute; and 

(b) segmenting means for segmenting the database, wherein a second heirarchy 
is created, the second heirarchy being associated with the attribute restriction value; and 

(3) a client computer coupled to Ihc server, wherein the client computer 
includes: 

(a) means for inputting from a user of the client computer the attribute 
restriction value; and 

(b) means for transmitting the attribute restriction value to the receiving means. 



2^ A database management system, characterized by 

(1) a database comprising data indicative of an organization; 

(2) a server computer coupled to the database, the server computer including: 

(a) querying means for querying the database in response to the occurrence of a 
defined trigger event or in response to a request to analyse the data in the database; and 

(b) report generating means for generating a report responsive to^the querying 
means; and 

(3) a client computer coupled to the server, the client computer including: 

(a) means for receiving the report generated by the report generating means; and 

(b) means for displaying the report to a user of the client computer. 
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3L A database management system comprising: 

(1) a database comprising data entities indicative of an organization, the data 
entities being arranged in a first hierachy with each level of the first heirarchy being 
associated with at least one attribute; 

(2) a server computer coupled to the database, wherein the server computer 
includes: 

(a) querying means for querying the database in response to the occurrence of a 
defined trigger event or in response to a request to analyse the data in the database; 

(b) report generating means for generating a report responsive to the querying 

means; 

(c) receiving means for receiving an attribute restriction value for restricting a 
selected attribute; and 

(b) segmenting means for segmenting the database to create a second heirarchy 
which is associated with the attribute restriction value; and 

(3) a client computer coupled to the server, wherein the client computer 
includes: 

(a) means for inputting from a user of the client computer the attribute 
restriction value; 

(b) means for transmitting the attribute restriction value to the receiving means 

(c) means for receiving the report generated by the report generating means; and 

(d) means for displaying the report to a user of the client computer. 
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3. Detailed Description of Invention 

The present invention relates to expert systems and reporting systems, and more 
specifically to a database management system for analysing and segmenting a computer 
database and for generating reports. 

In many applicatons, large amounts of transaction-level data are stored for later 
analysis (data warehousing). To make use of data warehouses, the data must be retrieved, 
organized and then presented in an understandable format 

Discovery tools are used to retrieve, analyze and present data from data 
warehouses. These tools can range from very complex modeling tools to relatively simple 
end user query tools designed to do no more than mask the complexity of the SQL database 
programming language from the user. Automated tools that search the data for trends or 
relationships are also considered discovery tools. 

The marketplace is comprised of various tool vendors whose products 
provide solutions for a portion of the entire knowledge discovery process. Therefore, to 
effectively utilize their data, the user community is forced to pick multiple, disjoint tools. 
In addition, these tools are targeted toward the expert user who has an in-depth knowledge 
of the data and database formats or the various analytic methods that are implemented in 
the tool. Existing products also do not let the user explicitly and iteratively represent 
knowledge. Finally, the output of existing tools consists of tables of numbers that users 
have to analyze and interpret. 

Data warehouses, and databases in general, typically have complex structure 
organized for efficiency of data retrieval, not ease-of-use by the end user. Users desire 
reports in their vocabulary, not the vocabulary of the database. While some tools in the 
marketplace allow a user to define new terms and map those terms to the database, the 
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management of related sets of new terms is not supported. That is, the relationship of a 
new term to existing terms is not automatically detected for the user. 

In addition to these difficulties, it is common for the contents of a report to 
cause a user to desire another, similar report. Saving and re-using sets of related reports 
(re-generating the reports over a new set of data) is also desired. The generation of related 
reports and the re-generation of reports over new data is a capability not adequately 
available in the marketplace. 

It is an object desirable to provide a system for generating reports from a 
computer database which allow a user to retrieve and analyze data with one tool without 
requiring the user to have knowledge of underlying data structures or of the database 
programming language, which allow a user to define new terms and detect and manage 
relationships between terms, which allow a user to easily generate related reports, and 
which allow a user to re-run sets of related reports over new data. It .is also an object of 
the present invention to provide a system allowing the a user to segment and partition a 
database based upon attributes associated with the data in the database. 

In accordance with a first aspect of the present invention, there is provided a 
database management system characterized by: 

(1) a database comprising data entities having associated attributes, wherein the 
data entities are arranged in a first heirarchy, each level of the first heirarchy being 
associated with at least one attribute; 

(2) a server computer coupled to the database, wherein the server computer 
includes: 

(a) receiving means for receiving an attribute restriction value for restricting a 
selected attribute; and 

(b) segmenting means for segmenting the database, wherein a second heirarchy 
is created, the second heirarchy being associated with the attribute restriction value; and 

(3) a client computer coupled to the server, wherein the client computer 
includes: 
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(a) means for inputting from a user of the client computer the attribute 
restriction value; and 

(b) means for transmitting the attribute restriction value to the receiving means, 
the database having the second heirarchy. 

According to a second aspect of the present invention, there is provided a database 
management system, characterized by 

(1) a database comprising data indicative of an organization; 

(2) a server computer coupled to the database, the server computer including: 

(a) querying means for querying the database in response to the occurrence of a 
defined trigger event or in response to a request to analyse the data in the database; and 

(b) report generating means for generating a report responsive to the querying 
means; and 

(3) a client computer coupled to the server, the client computer including: 

(a) means for receiving the report generated by the report generating means; and 

(b) means for displaying the report to a user of the client computer. 
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According to a further aspect of the present invention, there is provided a database 
management system comprising: 

(1) a database comprising data entities indicative of an organization, the data 
entities being arranged in a first hierachy with each level of the first heirarchy being 
associated with at least one attribute; 

(2) a server computer coupled to the database, wherein the server computer 
includes: 

(a) querying means for querying the database in response to the occurrence of a 
defined trigger event or in response to a request to analyse the data in the database; 

(b) report generating means for generating a report responsive to the querying 

means; 

(c) receiving means for receiving an attribute restriction value for restricting a 
selected attribute; and 

(b) segmenting means for segmenting the database to create a second heirarchy 
which is associated with the attribute restriction value; and 

(3) a client computer coupled to the server, wherein the client computer 
includes: 

(a) means for inputting from a user of the client computer the attribute 
restriction value; 

(b) means for transmitting the attribute restriction value to the receiving means 

(c) means for receiving the report generated by the report generating means; and 

(d) means for displaying the report to a user of the client computer. 
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Referring now to Fig. 1, system 10 includes four major subsystems: client 
subsystem 12, data abstraction intelligence (DAI) subsystem 14, data and schema 
manipulation (DSM) subsystem 16, and scheduler subsystem 18. 

In connection with the description of system 10, the following definitions are 
provided: 

An Alert Condition is a user-defined condition or set of conditions that when 
satisfied returns an Alert Message. For instance, an Alert Condition may be defined so 
that when the inventory of brand A shirts drops below 200 units for a given week, system 
10 produces an Alert Message, InfoFrame™ or runs another analyst. 

An Alert Message is a message that notifies the user that an Alert Condition 
has been satisfied. From an Alert Message the user can select the corresponding 
Information Report (InfoFrame™) to be run. An example of an Alert Message would be 
"Alert: the inventory of brand A shirts is below 200." 

An Alert Information Report (Alert InfoFrame 1 *) is a type of status report 
that describes an Alert Message in detail. The Alert InfoFrame™ has a description of what 
happened, when, and probable reasons why it occurred. 

An Analyst specifies an event in the data which must trigger an Alert; or 
specifies the type of analysis and the measures and segments to be reported on in an 
InfoFrame™, and optionally the schedule on which this InfoFrame™ is to be generated or 
the event in the data which must trigger the InfoFrame™. ' 
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An attribute is a characteristic or feature of an entity represented in the 
warehouse. For example, Color, Manufacturer, or Size are all attributes of the product 
category of Clothing. 

An attribute restriction is an expression that restricts the value that attribute 
can have. For example, in "Price is less than $10.00", the "less than $10.00" is a 
restriction on the Prices attribute. Another example might be: "Woman's Clothing or 
Men's Clothing" is a restriction on the Department Attribute. A single attribute value, like 
"Blue" or "Men's Clothing", is also an attribute restriction. 

A specific entity (like a product) in the data warehouse is represented as a 
set of attributes and values. For example, the product "Designer X men's shirt, size 42, 
color blue", might be represented as "Product: Department: Men's Clothing; 
Manufacturer Designer X; Size: 42; Color: blue". These values are members of specific 
domain for each attribute (see below). 

Indicators are classifications across Concepts that are usually related to 
numerical values (e.g. Sales Volume, Inventory, Price). Indicators have methods and 
formulae that pertain to their computation (e.g. Total Sales) and causal associations 
between Indicators (e.g. If Price increases Sales Volume should decrease). Within a 
Indicator, segments can be defined which describe a specific group of Indicators of interest 
(e.g. Senior Customer, Company A Products). 

A Change Analysis Report is a compound document describing Indicators 
over two time periods. Within system 10, one can specify two periods of time and sec the 
difference of a chosen Indicator for that period (e.g., How did this year's sales of textiles 
compare to last years sales?) Change Analysis Reports can report results for a day, week, 
month, quarter, year, or other defined period. 

A Comparison Analysis I nfoFrame 1 ** is a type of status report which helps a 
user compare the value of two Indicators across the same time period or compare the value 
of the same Indicator across two sibling segments across the same time period. 



8 



(136) 



ftmW-l 0-2 07 7 



Compound Indicators arc user-defined Indicators created by combining 
primitive Indicators with arithmetic and set operations. 

A Pata Warehouse is a very large collection of data that is housed in one or 
more databases. These databases usually reside on database server computers and can be 
either in one location or distributed geographically. 

A Dimension defines the high-level categories of entities. For example, in a 
Retail domain, the dimensions might be: Product, Market, and Time (Time is a universal 
dimension applicable to any domain). A dimension has associated with a set of attributes 
that can be used to describe its entities; for example, Brand, Manufacturer and Size 
describe the dimensions of a product. , 

Every attribute has an implicit or explicit domain of values. For example, 
the domain of values for the Department attribute is an encoding of the legitimate 
departments for the enterprise, and the domain of values for the Size attribute is a non-zero 
number representing the size in specified units. 

A PriH Down Heuristic specifies some relation between the measure values 
of the segments of a free attribute of a segment which must be reported to the user. 

End Vser$ are users for which system 10 is specifically designed. End users 
typically have knowledge of a user's operations and for this example have used Microsoft 
Windows™ (Windows 3. 1™, Windows NT™ 8c Windows 95™, etc.). End users typically 
do not have expertise in SQL code generation or the specific data structures of the 
databases they want to access. 

Enterprise Information Factory™ (EIF) is a commercial software package 
that allows typical users to access their data warehouse data. The data warehouse is 
essentially a passive environment that usually requires the use of SQL code and knowledge 
about the structure of the database to access data. The EIF differs from the data warehouse 
by providing a foundation for providing tools to allow users without SQL or database 
knowledge to get data out of their databases. 
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An Exception Analyst is specifically an Analyst which runs regularly to test 
for a trigger condition, and which returns an Alert or a Report when the trigger condition 
occurs. 

If the domain of an attribute is a finite set (like Department above), it is 
called a finite domain. The alternative is an infinite or continuous domain, like Price. 

A Free Attribute is an attribute of a segment which has not been restricted to 
define that segment. Color, Cost, and Weight might all be free attributes of the segment 
"Expensive Shirts* 

A Heuristic Rule specifies some condition of data, some relation between 
the segment measure values found by an analyst, that should be reported to the user in the 
completed InfoFrame™. 

HyperText Markup L anguage fHTML) is an emerging standard format for 
software documents that allows for the inclusion of hyperlinks and graphics (pictures, 
graphs, tables) in text documents. A hyperlink is a "hot" area in the document (usually 
text in a different color than the surrounding text), that when clicked on, shows another 
document that is related or linked to the original HTML document. 

InfoFrame 1 * Definitions are System Templates that have been customized to 
include particular Concepts, Indicators, Time Intervals, Analysis Type, and segments. 
InfoFrame™ Definitions can be immediately "run" to produce a "rnfoFrame™", saved to 
be run later, saved and scheduled to be run later, or triggered by another analyst. 

A Knowledg e Worker is typically a person familiar with SQL, who knows 
the structure of the Data Warehouse and who has an analytical background. In addition, 
the Knowledge Worker may use statistical and data analysis packages and data modeling 
tools. 

Managament Discovery Tool ™ fMDT) refers to the overall system of the 
present invention. 

Metadata™ is the collection of information about the end user's particular 
operation and may be one of three types: core, public or private. After installation this 
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information is stored in the end user's database and is used to tailor reports to the end 
user's particular needs. Metadata™ includes, but is not limited to, Concepts, Indicators, 
Segments, Attributes, Attribute Values and Measure Relationships. 

The core set of Metadata™ is typically set up at installation by professional 
services personnel and the MDT Administrator. Core Metadata™ consists of Dimensions, 
Attributes, Basic Measures, Segments and Year definitions. 

Public Metadata™ is only changeable by the MDT Administrator and 
Knowledge Worker user types and is defined and modified after installation. Public 
Metadata™ includes Public Composite Measures, Public Measure Relationships and Public 
Segments. 

Private Metadata™ belongs to each user and is only changeable by the end 
user (executive user) user type. Private Metadata™ includes Private Composite Measures, 
Private Measure Relationships and Private Segments. 

If an attribute has a finite domain, die Natural Partition is the partition 
where each segment corresponds to each element of the domain. For example, the natural 
partition of the Department attribute is the set of segments "Men's Clothing", "Woman's 
Clothing w , etc. 

Object Li nking and Embedding (OLE) is a computer format that allows 
objects (e.g., graphs, tables) in computer documents to, when double clicked on, bring up 
the software application that created the object (graph, table, document). 

If the user-defined segments for a given partition do not cover the domain, 
then an "Other" segment will stand for the rest of the partition. 

A partition is an implicit or explicit division of the dimension by the 
restriction of a single attribute. For example, of one takes the Price attribute, and the "less 
than $10.00" restriction, this defines a partition of products into two sets or segments: 
those products with Price less than ten dollars, and those products with Price greater to or 
equal to ten dollars. Note that the sets or segments of a partition must cover the original set 
and not overlap, i.e., "Price < $10.00* and "Price < $15.00" do not define a partition. 
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Primitive Indicators arc Indicators that are directly mappable to data in the 
data warehouse. They are set up during installation of the present invention and are not 
. changeable by the end user. 

Reports or InfoFrames™ are compound documents that display data from a 
database in text and graphics (e.g., graphs, tables). Reports are the result of running a 
InfoFrame™ Definition. InfoFrames™ may be in the HTML format and may be OLE 2.0 
compliant. 

A Restricted Attribute is an attribute of a segment which has be restricted to 
defined the segment. Product and Price might be the restricted attributes of "Expensive 
Shirts" 

Segments are user-defined groups that are defined within a Concept having a 
meaningful attribute or attributes in common. For instance, the segment "Senior 
Customers" might be those customers whose age is greater than 65 years. 

A segment is one part of a partition. Actually, a segment is a subset of data 
defined by restrictions on one or several attributes. If a segment is defined by several 
attributes, it can be part of several partitions, one for each restricted attribute (as shown 
shortly. This means that, given a segment in isolation, one cannot determine which 
partition it "should" belong to, and thus, one cannot determine its natural parents in the 
hierarchy). 

A set of segments forms a segment hierarchy under the subset relation, with 
a root that is the "top-level segment", which contains all of the members of the dimension. 

Structured Query La nguage (SOU) is a structured language for viewing the 
contents of a relational database. 

Summariza tion InfoFrame 1 * 1 is a type of InfoFrame™ that shows a roll-up or 
summarization of a specified Indicator across one or more specified segments. By 
selecting a particular Indicator in this report a InfoFrame™ showing the " winners'* and 
"losers" for the specified period can be automatically produced. 
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System Administrators (MDT Administrators, or MDTA) are those users of 
system 10 who have an intimate knowledge of the databases and data structures of an 
organization. Often the System Administrator has the title of "database administrator* 
(DBA). 

A Text Generation Rule specifies the text that must be inserted into an 
InfoFrame™ when the some heuristic rule is satisfied. 

A Trend Analysis InfoFrarPC™ is a type of InfoFrame™ that, when defined, 
shows the trend for a specific Indicator or indicators over a specified period of time. This 
analysis can aid in forecasting the future by identifying patterns in past activities. 

Client subsystem 12 is a single application program which has a graphical 
user interface (GUI) 40 and which allows a user to select and specify parameters for 
InfoFrames™, view InfoFrames™, print InfoFrames™, and save InfoFrames™. Finally, the 
user can define Composite Indicators and Segments, create Analysts, define Measure 
Relationships, or modify the schedule of Analysts. 

DAI subsystem 14 provides intelligent middleware for translating graphical 
user requests, selecting system templates, manipulating data views, and generating 
dimensional queries for retrieving data from data warehouse 24. It also contains rules for 
choosing default parameters, for choosing layout and display formats, and for generating 
text from data. DAI subsystem 14 is responsible for instantiating user selected 
InfoFrames™ and managing several kinds of Metadata™ 25 used in this instantiation. This 
Metadata™ 25 represents Concepts and Indicators that provide a customizable 
"dimensionalization* of the relational data in data warehouse 24. DAI subsystem 14 also 
processes updates to this Metadata™ 25 that originate in client subsystem 12 and handles 
several other kinds of user updates, primarily by passing them to DSM subsystem 16. 

DSM subsystem 16 reads schema from data warehouse 24, creates data 
views, and creates a mapping between the two. It also uses that mapping to translate the 
Dimensional Queries received from DAI subsystem 14 into SQL and package and return 
the results. 
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Scheduler subsystem 18 is responsible for for starting Analysts which are to 
run at a scheduled time or on a regulare schedule; or Exception Analsysts which must 
regularly test for a trigger condition in the database.. When the requested time interval 
occurs, the Scheduler starts up, requests a list of scheduled InfoFrame™ Requests from 
DAI subsystem 14. From those lists, scheduler subsystem 18 determines which should be 
run during the current time interval and sends those requests to DAI subsystem 14 as if 
they were sent by client subsystem 12. 

Thus, system 10 is implemented as a three-tier architecture. Client 
computer 30 executes client subsystem 12. Client computer 30 preferably executes 
Windows NT™, or Windows 95™, although other operating systems are also envisioned 
by the present invention. Client subsystem 12 (Figs. 6-12) is suitable for use with these 
operating systems. Display 22 and input device 21 allow a user to view GUI 40 and enter 
choices of Metadata™ 25 used in creating Analysts. Input device 21 may be a keyboard, 
mouse, or other pointing device. Printer 23 allows a user to print a InfoFrame™. Storage 
medium 26 allows a user to store an InfoFrame™ or Alert Message. 

Server computer 32 executes DAI subsystem 14, DSM subsystem 16, and 
scheduler subsystem 18. These three subsystems combine to satisfy user requests from 
client subsystem 12 using information from data warehouse 24. Server computer 32 is 
preferably a multi-processor computer and executes the UNIX ™ operating system or 
Windows NT ™, although other computer and operating system configurations arc also 
envisioned by the present invention. 

Client and server computers 30 and 32 are preferably coupled 
asynchronously for report requests; all other requests are satisfied synchronously. 
Communication between client and server computers 30 and 32 is preferably through 
transmission control protocol/ internet protocol (TCP/IP), although other transmission 
protocols are also envisioned by the present invention. 

Database computer 34 includes one or more storage media 36 containing 
data warehouse 24. Database computer 34 is preferably a massively parallel processor 
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computer and executes the UNIX ™ operating system or Windows NT ™, although other 
computer and operating system configurations are also envisioned by the present invention. 
Data warehouse 24 is suited to run on any computer which supports an Open Database 
Connect (ODBC) interface to data warehouse 24. Communication between server 
computer 32 and database computer 34 is preferably via ODBC, although other database 
interfaces are also envisioned by the present invention. 

Turning now to Fig. 2, client subsystem 12 is an application program which 
gives a user control over system 10 and is suitable for execution on top of the Windows 
NT ™, or Windows 95 ™ operating systems. Client subsystem 12 includes log-in module 
50, folder management subsystem 54, segment builder 55A, measure builder 55B and 
measure relationship builder 55C, analyst definition subsystem 56, InfoFrame™ viewing 
subsystem 53 and MDT Administrator interface 57. 

Log-in module 50 verifies that only one copy of the client subsystem 12 is 
running on computer 30, checks the localization of computer 30, connects to computer 32, 
and interacts with the user to log him onto client subsystem 12. During logon, log-in 
module 50 verifies a user's name and password and then retrieves any user preferences that 
may have been earlier defined. The only request from a user that is handled by log-in 
module 50 is a request to log onto client subsystem 12. 

Log-in module 50 issues the following requests: 



• single program running 


to Operating System (DOS ™, NT ™, 
Windows 95 ™ f etc.) 


• retrieve localization 


to Operating System (DOS ™ f NT ™ 
Windows 95 ™, etc.) 


• connect to server 


to Client/Server module 


• disconnect from server 


to Client/Server module 


• authenticate user 


to Metadata™ API 60 


• run main menu 


to Mam Menu 5 1 


• run admin menu 


to MDT Administrator Interface 57 
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If the user is the Sysfem Administrator, log-in module 50 displays MDT 
Administrator interface 57 "Setup" menu item. If the user is an end user or knowledge 
worker, a Main menu and toolbar interface 51 are displayed, as are the interfaces 
associated with subsystems 53-55. 

MDT Administrator interface 57 is used by a System Administrator to 
perform system administration tasks, such as making user-defined segments available 
globally and creating and editing Concepts. Interface 62 is preferably only available to 
System Administrators during system installation. 

Folder management subsystem 54 handles all functions related to 
manipulating, storing, and retrieving Folder hierarchies, and the InfoFrames™ and Agents 
that are stored in those Folders. It also handles querying from DAI subsystem 14 for 
newly-completed InfoFrames™, both when client subsystem 12 starts up, and then 
periodically thereafter. 

Folder management subsystem 54 also handles User requests for operations 

on; 

* Folders (new, delete, rename) 

* Agents (edit, delete, run now, print) 

* InfoFrames™ (view, delete, annotate, print [in cooperation with 
the InfoFrame™ View Window]) 

Each folder is represented by one folder object. A folder stores a list of 
child folders, a list of InfoFrames™, and a list of Agents. Folder objects are created and 
deleted by folder management subsystem 54 in response to user requests. 

Subsystems 55B provides a user with the ability to create new measures, 
update measures, or delete existing measures. This information is sent to a Metadata™ API 
60 and thereafter to DAI subsystem 14 for updating the user's Metadata™ 25. 



16 



(144) 



ftffl 1 ? 10-207751 



Subsystem 55A provides a user with the ability to create new Segments, 
update segments, or delete existing Segments. This information is sent to a Metadata™ 
API 60 and thereafter to DAI subsystem 14 for updating the user's Metadata™ 25. 

Finally, Subsystem 55C provides a user with an interface to modify measure 
relations and to constrain measure relations. The user selects the current measure and 
whether to evaluate that measure's relationships when it increases or decrease. Then the 
user can then select from a list of other measures and define their relationship to the 
current measure. These relationships are in the form of "decreases", "increases", or "is 
unrelated to the current measure". Also, every relationship between two measures can be 
constrained. The relationship between measures and the constraints placed upon them are 
saved on computer 32 for use in generating InfoFrames™. 

Analyst definition subsystem 56 handles all functions related to user 
selection of parameters needed to generate specific reports. It also allows the user -to 
define and schedule Alerts for scheduled reports. 

The user may invoke an existing Analyst, delete one from within the folder 
management subsystem 54, or create a new Analyst. The five types of Analysts are: 

• Summarization 

• Segment Comparison 

• Measure Comparison 

• Change Analysis 

• Trend Analysis 

The Summarization Analyst requires the following user selection 

requirements: 

• Analyst name 

• Primary measure, other optional measures 

• Primary segment, other segments 

• Time period 
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• Optional schedule 

• Optional trigger 

• type of year used 

• optional trigger event (Alert Message, InfoFrame™, Run another analyst) 
The Segment Comparison Analyst requires the following user selection 

requirements: 

• Analyst name 

• Primary measure 

• Primary segment, a comparison segment 

• Time period 

• Optional schedule 

• Optional trigger 

• type of year used 

• optional trigger event (Alert Message, InfoFrame™, Run another analyst) 
The Measure Comparison Analyst requires the following user selection 

requirements: 

• Analyst name 

• Primary measure, Comparison measure 

• Primary segment, other optional segments 

• base time period, comparison time period 

• Optional schedule 

• Optional trigger 

• type of year used 

• optional trigger event (Alert Message, InfoFrame™, Run another Analyst) 
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The Change Analysis Analyst requires the following user selection 

requirements: 

• Analyst name 

• Primary measure 

• Primary segment, Other optional segments 

• base time period, comparison time period 

• Optional schedule 

• Optional trigger 

• type of year used 

• optional trigger event (Alert Message, InfoFrame™, Run another Analyst) 
The Trend Analysis Analyst requires the following user selection 

requirements: 

• Analyst name 

• Primary measure 

• Primary segment, other optional segments. 

• Time period, Time interval. 

• Optional schedule 

• Optional trigger 

• type of year used 

• optional trigger event (Alert Message, InfoFrame™, Run another Analyst) 

The user can save or run the analyst definition. The user is restricted to 
choosing one Segment from within each Concept with the exception of Target Segment, in 
which case he may select only one segment and more than one child partition of the 
selected segment. The user may choose to schedule an Analyst or to modify or delete an 
existing schedule. Unscheduled Analysts will be run when the user commands. Scheduled 
Analysts will be submitted to the server for execution at a later date or periodic execution. 
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The user may specify a trigger condition for the Analyst to specify an 
Exception Analyst. When submitted to the server it will be run regularly to test for its 
trigger condition, and will return an Alert or an InfoFrame™ whenever the trigger 
condition occurs. 

The Analyst definition subsystem 56 makes the following requests to the 
folder management subsystem 54: 



Save 


Check if the user has selected the 
appropriate parameters for the selected 
analyst. Send a request to the folder 
management subsystem 54 to save an 
existing Analyst Definition 


Save As 


Check if the user has selected the 
appropriate parameters for the selected 
analyst. Send a request to the folder 
management subsystem 54 to save an 
existing Analyst Definition 


Submit 


Check if the user has selected the 
appropriate parameters for the selected 
analyst. Send a request to the folder 
management subsystem 54 to submit a 
report generation 


The Analyst definition subsystem also makes the following requests to 
Metadata™ API 60: 


Get all Measures 


The request will be made to Metadata™ 
API 60 each time there is a need for it at 
the initialization point of a dialog 


Get all Concepts 


The request will be made to Metadata™ 
API 60 subsystem each time there is a 
need for it at the initialization point of a 
dialog 


Get a Concept's Partitions 


The request will be made depending on a 
user's selection of a concept 


Get Partitions 


The request will be made depending on a 
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user selection of a defined Segment. 


Get Segments 


The request will be made depending on a 
user selection of a partition. 



InfoFrame™ viewing subsystem 53 includes a WYSIWYG browser which 
displays a selected InfoFrame™ on screen, when InfoFrame™ viewing subsystem 53 gets a 
notification from folder management subsystem 54 to view a InfoFrame™. If the user 
decides to drill down from the current InfoFrame™, InfoFrame™ viewing subsystem 53 
notifies the folder management subsystem 54 to send a new report request. 

When the user double-clicks on an InfoFrame™ or chooses "menu item - 
View** from the File menu Folders, the folder management subsystem 54 notifies the 
InfoFrame™ viewing subsystem to view the InfoFrame™. When the user clicks on a 
hypertext to drill down from the current InfoFrame™, the InfoFrame™ viewing subsystem 
53 passes the drill down information to the folder management subsystem 54 to send a new 
report request to DAI subsystem 14. 

InfoFrame™ viewing subsystem 53 includes a parser which parses the 
InfoFrame™, and extracts the completed report, which is written in HTML. In an HTML 
file, HTML tags indicate document elements, structure, formatting, and hypertext linking 
to other documents or resources. The parser then outputs all the information for display. 
In the current invention, the hyperlink may instance a new Analyst and a new InfoFrame™ 

The InfoFrame™ viewing subsystem 53 allows a user to display and format 
text, tables, and graphs displayed by display 22 based on the information gathered by the 
parser. A header, a footer, and annotations can be added to a InfoFrame™. The user can 
save the viewed InfoFrame™. The user can also save an InfoFrame™ as a HTML file in 
cither UNICODE or ASCII code format. A saved HTML InfoFrame™ can be attached to 
an e-mail to mail out. Any HTML version 3.0 browser, or equivalent, can read the 
HTML InfoFrame™. 

Metadata™ API 60 handles most of the communications between client 
subsystem 12 and DAI subsystem 14. These communications involve four basic types of 
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data: Metadata™ 25, InfoFrames™, user profiles, and data warehouse schema. For 
Metadata™ communication, Metadata™ API 60 provides the ability to add, delete and 
update Metadata™ 25. For InfoFrames™, Metadata™ API 60 provides the ability to 
request a report, get the status of a report, retrieve a report and cancel a report request. 
For user profiles, Metadata™ API 60 provides the ability to add a user, authenticate a user 
and delete a user. The communication for data warehouse schema is to retrieve it. 

Metadata™ API 60 allows a user to define new ways of looking at an* 
operation. A user cannot modify the public segments, the basic measures or the public 
measures. However, the user can create new Indicators and new Segments. In a typical 
organization of users and system administrators, only system administrators can create or 
change basic operation measures. Administrators and knowledge workers can create, edit 
or delete public composite measures, public segments and public measure relationships. 

The Metadata™ API 60 will handle the following requests from other client 

subsystems: 



update Metadata™ 


from subsystems 55A/55B/55C 


get report status 


from Folder management subsystem 54 


generate report 


from Folder management subsystem 54 


retrieve report 


from Folder management subsystem 54 


retrieve schema 


from MDT Administrator Interface 57 


update schedule 


from Analyst Definition subsystem 56 


cancel a report 


from Analyst Definition subsystem 56 


authenticate user 


from Log-in module 50 


add a user 


from MDT Administrator Interface 57 


delete a user 


from MDT Administrator Interface 57 


update user password 


from MDT Administrator Interface 57 



Metadata™ API 60 sends the following requests directly to DAI subsystem 

14: 

• disconnect from computer 32 

• send data to DAI subsystem 14 
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• receive data from DAI subsystem 14 

Turning now to Fig. 3, DAI subsystem 14 includes return area manager 70, 
InfoFrame™ generator 72, Metadata™ request module 74, Metadata™ repository 76, and 
Metadata™ load and update module 78. 

Metadata™ repository 76 contains a representation of Metadata™ 25 within 
data warehouse 24. This Metadata™ 25 is the core of system 10; it provides a customizable 
view over the relational data in warehouse 24 and is the primary vocabulary for the 
specification of InfoFramcs™. Metadata™ repository 76 gets populated at startup time by 
DSM subsystem 16 from Ihe persistent Metadata™ representation in data warehouse 24. 

There are four fundamental kinds of Metadata™ 25 in Metadata™ repository 
76 t listed and described below: . 

• Cpncepts: concepts represent the dimensions along which the data can be viewed. Each 
dimension imposes a hierarchy over the underlying data, and dimensions can be 
combined to drive "drill-down- or "drill-up" operations. For example, a simple retail 
application might have two Concepts: Market and Product. The Market hierarchy is 
composed of Sales Regions, each of which consists of several States, each of which 
consists of a set of Stores. The Product Hierarchy is composed of a set of Departments 
(Home Electronics, Men's Clothing, Hardware), each Department is composed of 
product Categories (Shirts, Shoes, Slacks), and each Category is composed of 
individual manufacturer's product lines. Time is a dimension that is important in all 
applications, and will be represented in system 10. Users can add new Concepts (see 
below). These, as all of the Metadata™ 25 in Metadata™ repository 76, must be 
mapped into relational form (that is, into SQL) in order to actually query data 
warehouse 24. Mapping is done by DSM subsystem 16 during the process of 
processing Dimensional Queries (see below). 

• Indicators: Indicators are the important measures of data of interest. For example, 
product Volume, Price, or Current Stock are all Indicators. The use of time in a query 
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further refines the idea of a Indicator; for example, "Change in Volume" applies 
between two time periods. 

• Alerts: Alerts are essentially tests over the data, but they are not part of the Metadata™. 
They are specified in the Analyst in terms of the Metadata™. For example, a user 
might specify that if the available stock of a product falls by some percentage, to 
generate the appropriate InfoFrame™. The user also specifies how often to check the 
Trigger condition. A list of Alerts is maintained by DAI subsystem 14 and executed by 
scheduler subsystem 18. This Metadata™ 25 is also available to DAI subsystem 14 and 
is used to generate InfoFrame™ information. 

• Measure Relationships: Measure Relationships are simple expressions of causality; for 
example, "Increased Sales mean Increased Profit*. This kind of Metadata™ 25 is used 
to generate supporting information for a InfoFrame™ or, alternatively, alert the user to 
trends that run counter to the set of Measure Relationships. 

Metadata™ 25 is initially created during installation of the present invention 
at the customer's site. The process of creating the Metadata™ 25 is illustrated in more 
detail in Figs. 7A-7E. What is included within Metadata™ 25 depends on the industry 
(some Metadata™ 25 will be industry-specific and usable by all companies in that industry), 
the specific customer of the present invention, and the structure of the customer's data 
warehouse 24. During installation, some industry- specific Metadata™ 25 is used, some 
company specific Metadata™ 25 may be created, and the mapping information needed to 
map Metadata™ 25 to data warehouse 24 is created. All Metadata™ 25, including the 
mapping information, is stored in a set of relational tables. These relational tables are kept 
in data warehouse 24 and used by the present invention to create reports for the user. 

Metadata™ request module 74 handles alt requests for Metadata™ 25, either 
from client subsystem 12 or DAI subsystem 14. Client subsystem 12 requests Metadata™ 
25 from DAI subsystem 14 to be presented to the end users. InfoFrame™ generator 72 
requests Metadata™ 25 in order to create Dimensional Queries as part of instantiating a 
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InfoFrame™ for a user. A request for Metadata™ 25 might be, for example, a request for 
aJl sub-concepts of a particular Concept. 

Metadata™ request module 74 also handles Metadata™ updates from client 
subsystem 12. A user adds new Segments by specifying a new dimension from which to 
group the data. This dimension must be supported by an existing data attribute in the 
warehouse data. For example, a Product may include a List-Price and a Discount-Price. 
The user can specify a new dimension called "Discount-Factor", specified using the 
percent difference between the Discount-Price and the List-Price, and use that to create 
three new Segments: Heavily-Discounted Products, Slightly-Discounted Products, and 
Non-Discounted Products. These new Segments can now be used in subsequent 
InfoFrame™ requests, and, if indicated by the user, made persistent by writing them back 
into data warehouse 24 by Metadata™ load and update module 78. 

Request Structures are passed from one subsystem to another when one 
subsystem requires processing and results from another. Request Structures vary according 
to the type of request being sent. Most requests, however, have some common attributes, 
such as an identification field, an owner, a name and a description of the request. 

Concept Update Requests are sent from client subsystem 12 to DAI 
subsystem 14 and are preferably issued only by the System Administrator. Concept Update 
Requests are requests for adding a new Concept to the Metadata™ 25. The requests have 
the following format: 



BC ID: 


ID which uniquely identifies this Concept 


BC NAME: 


The name of this Concept 


BC DESC: 


The description of this Concept 


MAPPING: 


Mapping of this Concept to data warehouse tables 
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Indicator Update Requests are sent from client subsystem 12 to DAI 
subsystem 14. Indicator Update Requests are requests for adding a new Indicator to the 
Metadata™ 25. 

Indicator Update Requests primarily include primitive and compound 
requests. Primitive requests have the following format: 



BI. ID: 


ID which uniquely identifies this Indicator 


OWNER: 


The user who created this Indicator 


BI NAME: 


The name of this Indicator 


BI DESC: 


The description of this Indicator 


MAPPING: 


Mapping of this Indicator to data warehouse tables 


ROLLUP OP: 


Operator for performing the roll-up operation 


Compound requests have the following format: 


BI ID: 


ID which uniquely identifies this Indicator 


BI NAME: 


The name of this Indicator 


BI DESC: 


The description of this Indicator 


EXP: 


The expression which describes this Indicator function 



Causal Indicator Update Requests are sent from client subsystem 12 to DAI 
subsystem 14. Causal Indicator Update Requests add a new Causal Indicator to the 
Metadata™ 25. The request has the following format: 



CI ID: 


ID which uniquely identifies this Casual Indicator 


OWNER: 


The user who created this Causa! Indicator 


CI NAME: 


The name of this Causal Indicator 


CI DESC: 


The description of this Causal Indicator 


BIIDl: 


Indicator which is the independent variable of this causal 
relationship 


OP: 


The operator for this causal relationship 


BI ID2: 


Indicator which is the dependent variable of this causal relationship 


RANGE: 


When OP is +/- f the range where it is -J- and the range where it is - 
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Schema Requests are sent from client subsystem 12 to DAI subsystem 14 
and may only be issued by the System Administrator. Schema Requests are requests to 
retrieve the data base schema from data warehouse 24. This type of request is just a 
simple unformatted message to DAI subsystem 14. 

Segment Update Requests are sent from client subsystem 12 to DAI 
subsystem 14. Segment Update Requests are requests for adding a new Segment to the 
Metadata™ 25. Segment Update Requests have the following format: 



SEG ID: 


ID which uniquely identifies this Segment 


OWNER: 


The user who created this Segment 


SEG NAME: 


The name of this Segment 


SEG DESC: 


The description of this Segment 


SEG LEVEL: 


Level in the Segment Hierarchy of this Segment 


DC ID: 


The Concept for this Segment 


ATTR ID: 


The Attribute(s) for this Segment 


OP: 


The operator(s) for this Segment 


VALUE: 


The value (s) for this Segment 



InfoFrajnc™ Requests are sent from the Client subsystem to the DAI 
This type of request is to create a new InfoFrame™ based on user specified 
The request has the following format: 



SR ID: 


ID which uniquely identifies this InfoFrame™ 


OWNER: 


The user who created this InfoFrame™ 


SR NAME: 


The name of this InfoFrame™ 


SR DESC: 


Hie description of this InfoFrame™ 


SR TYPE: 


One of the four types of InfoFrames™ 


DC ID: 


The Concept for this InfoFrame™ 


SEG ID: 


The Segment(s) for this InfoFrame™ 


TIME: 


The time interval (s) for this InfoFrame™ 



subsystem, 
selections. 
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Dimensional Queries are sent from DAI subsystem 14 to DSM subsystem 
16. Dimensional Queries formulate requests for data from data warehouse 24. DSM 
subsystem 16 converts Dimensional Queries into SQL statements. 

The DAI subsystem 14 communicates a dimensional query to the DSM 
subsystem 16 as a list of Metadata™ segment definitions or partition definitions, a list of 
Metadata™ measure definitions and a Measure Value Table. The DSM subsystem 16 
converts these to SQL Queries and submits them to the Data Warehouse 24. The results 
returned by the Data Warehouse to the DSM are returned to the DAI in the Measure Value 
Table. 

Client subsystem 12 produces the following outputs to DAI subsystem 14: 

• Concept Update Requests 

• Indicator Update Requests 

• Causal Indicator Update Requests 

• Schema Requests 

• Segment Update Requests 

• InfoFrame™ Requests 

• Cancel Requests 

DAI subsystem 14 provides the following outputs to client subsystem 12: 

• Concept Structures 

• Indicator Structures 

• Causal Indicator Structures 

• Schema Structures 

• Segment Structures 

• InfoFrames™ 

• Error/Status Codes 
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DAI subsystem 14 provides the following outputs to scheduler subsystem 18: 

• Schedule Analyst Request 

• Delete Analyst Request 

DAI subsystem 14 provides the following outputs to DSM subsystem 16: 

• Dimensional Queries 

• Metadata™ Retrieval Requests 

• Schema Requests v 

DSM subsystem 16 provides the following outputs to DAI subsystem 14: 

• Updated Metadata™ 

• Data from the Data Warehouse 

• Database Schema 

DSM subsystem 16 provides the following outputs to data warehouse 24: 

• SQL Statements 

DSM subsystem 16 receives the following inputs from data warehouse 24: 

• Metadata™ 

• Database Schema 

• Warehouse Data 

Scheduler 18 provides the following output to DAI subsystem 14: 

• Analyst Definitions 

Metadata™ load and update module 78 populates Metadata™ repository 76 
from the persistent Metadata™ stored in data warehouse 24 upon system startup. In 
addition, when a user specifies new Concepts and indicates that he wants them saved, 
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Metadata™ load and update module 78 writes them back into data warehouse 24 for future 
use. 

InfoFrame™ generator 72 fulfills the primary purpose of DAI subsystem 14. 
Report generation. begins when a user's Analyst containing an InfoFrame™ definition is 
received by the DAI. The type of Analyst is used to select appropriate Drill Down 
Heuristics and Text Generation Rules from the set implemented in the DAI. Drill Down 
Heuristics arc used to determine if there any data relationships between the segments of the 
free attributes of the target segment which must be reported. Text Generation Rules are 
used to determine what features of the target segment ought to be reported and what 
relationships to sibling segments, other segments in the restricted attributes of the target 
segment, ought to be reported. Text Generation rules may specify localizable text, graphs 
or tables as appropriate output. The output of the Report Generation process is a fully 
instantiated InfoFrame™ returned to client subsystem 12 in the form of HyperText Markup 
Language (HTML), a widely-used standard for building portable compound documents. 

InfoFrame™ generator 72 has several kinds of knowledge: 

• Knowledge of how to map Abstract Queries into Dimensional Queries 

• Knowledge of how to use Metadata™ 25 to generate default choices (choices 
not made by the user in the InfoFrame™ Request) 

• Knowledge of how to use both Metadata™ 25 and data returned from the 
warehouse to guide the selection of both text components 

• Knowledge of how to use both Metadata™ 25 and data returned from the 
warehouse to guide the selection of different types of graphical 
presentations. 

For example, the Summary InfoFrame™ may take as arguments a Concept, 
a Indicator, and a time period. The Report Generation Module uses the user selected 
parameters, for example, the Concept "Product", the Concept Segment "Men's Shirts", 
the Indicator "Volume'*, and the time period "December 1994" to create a Dimensional 
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Query. This Dimensional Query is sent to the Data and Schema Manipulation subsystem, 
which translates this query into SQL and actually executes it. It returns the computed data 
to DAI subsystem 14, where other Abstract Queries might embed the actual number in a 
bullet. 

Other Abstract Queries have conditionals associated with them. To build off 
the previous example, another part of the summary System Template might specify the 
creation of a graph, showing how the target-business-indicator (volume) is apportioned 
among the segments of the target-business-concept (shirts). In this case, report generator 
72 makes a Metadata™ request to return the set of segments, in this example, the dimension 
that specifies the shirt manufacturer. All volume information is requested for each 
manufacturer of shirts. Now, additional information guides report generator 72 in the 
selection of a choice of graph. For example, if the number of segments (manufacturers in 
this case) is small, like 7 or less, then a pie graph is appropriate, otherwise, a bar graph is 
preferred. If the number of segments is very large, then aggregate the bottom 20 percent 
(in terms of the Indicator, in this case, Volume) and use that aggregate with the label 
"Other" in the graph. 

Return area manager 70 keeps track of InfoFrames™ and Alert Evaluations 
with positive results by user that are waiting for delivery to client subsystem 12. When a 
user logs into system 10, client subsystem 12 issues a request to DAI subsystem 14 to 
return all data for that user in the return area. Return area manager 70 retrieves the 
information from the return area on server computer 32 and sends it back to client 
computer 30 through DAI subsystem 14. 

Turning now to Fig. 4, DSM subsystem 16 includes SQL generator 80 and 
Metadata™ query module 82. 

SQL generator 80 translates dimensional queries received from DAI 
subsystem 14 into SQL statements used to retrieve data from data warehouse 24. A 
mapping from concepts to database entities is stored in the Metadata™ 25 and is used in the 
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formatting of the SQL statements. SQL generator 80 provides to DAI subsystem 14 for 
use in creating InfoFrames™. 

Metadata™ query generator 82 processes requests for Metadata™ 25 
submitted by DAI subsystem 14. At system startup, DAI subsystem 14 requests all 
Metadata™ 25 in order to initialize the knowledge base. Metadata 7 " query generator 82 is 
also invoked whenever the user modifies his Segments, causing DAI subsystem 14 to issue 
an update Metadata™ request. 

Turning now to Fig. 5, scheduler subsystem 18 includes alert and report 
scheduler 90. The scheduler periodically tests queued Scheduled Analysts and will dispatch 
those to the have come due to the DAI subsystem 14. It will periodically dispatch all 
submitted Exception Analysts to the DAI subsystem 14 so that they can test for trigger 
conditions. The schedule and trigger periods are independently configurable by the MDT 
Administrator. The scheduler passes analysts to the CDAI 14B, by way of the Dispatcher 
2513 (Fig. 27). 

Turning now to Tigs. 6-12, client subsystem 12 and its operation are 
illustrated in more detail. 

Client subsystem 12 includes a primary overlay 98 which appears when 
client subsystem 12 is executed. Overlay 98 includes three display areas 100-104 within a 
common Folders window, pull-down menus 106, and buttons 110-120. The Folders 
window may be maximized (as it is shown in Fig. 6) to eliminate its borders, resized, or 
minimized as an icon within client subsystem 12. The Folders window cannot be closed. 

Display area 100 contains a list of folders, which represent the metaphor 
used by client subsystem 12 in organizing InfoFrames™ and the analysis that creates them. 
A folder is opened by highlighting it and selecting it with input device 21. The first folder 
in the list is opened by default when client subsystem 12 is executed. 

Display area 102 contains a list of InfoFrames™ within a selected folder. A 
InfoFrame™ may be viewed by highlighting it and selecting it with input device 21. An 
Analysis window 136 appears containing the InfoFramc™. The title bar of the window 
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indicates the type of preselected analysis that has been performed. For example, in Fig. 
12, "change" analysis was preselected by a user to be the type of analysis to run. The 
Analysis window 136 may be maximized (as it is shown in Fig. 12) to eliminate its 
borders, resized, or minimized as an icon within client subsystem 12. The Analysis 
window 136 may be closed by selecting button 122 (Fig. 12) or by a manner well known 
to users of Windows 3. 1™, Windows 95™, and other windows operating environments. 

Display area 104 contains a list of Analysts within a selected folder. An 
Analyst is a personification of preselected operations performed on preselected data for the 
purpose of generating a InfoFrame™. An Analyst may be viewed by highlighting it and 
selecting it with input device 21. Analyst Builder windows 130 (Figs. 7A-7E) appears 
containing the preselected settings saved within the Analyst and used to generate the 
corresponding InfoFrame™ listed in display area 102. (The InfoFrames™ listed in display 
area 102 are arranged in the same order as the Analysts listed in display area 104, and have 
the same titles as the corresponding Analysts). The Analyst Builder window 130 may be 
not be maximized, resized, or minimized as an icon; it may only be closed in a manner 
well known to users of Windows 3. 1™, Windows 95™. and other windows operating 
environments. 

Buttons 310-122 (Fig. 6) implement the primary operational commands 
within pull-down menus 106 and are activated using a pointing device. Button 110 calls 
the Analyst Builder windows 130 (Figs. 7A-7E). 

Button 112 calls a Segments divider within a Information Setup window 132 
(Fig. 8A). Button 1 16 deletes a selected file or folder within display areas 100-104. 
Button 118 creates a new folder. Button 120 calls the Analysis window 136 with a selected 
InfoFrame™ from display area 102. Button 122 closes client subsystem 12. Button 150 is 
a print button, button 151 allows the user to create measures, and button 152 allows the 
user to create or edit measure relationships. 

With reference to Figs. 7A-7E, Analyst Builder window 130 allows a user 
to define how selected data is analyzed. An Analyst is named under the Analyst Name 



33 



(16 1) »RJ¥ 1 0-20775 1 

field. A type of analysis is chosen under the Type of Analysis field. A primary measure 
to be used in implementing the analysis is chosen under the Primary Measure field. 
Segments to be reported on are chosen from the list of Defined Segments. Finally, a 
period for the InfoFramc™ is defined under the Time Slice Considered fields. A 
InfoFrame™ can be created immediately by selecting the Report Now button, or can be 
scheduled as part of a batch of InfoFrames™ by selecting the Schedule Analyst button. 

With reference to Fig. 8A, the Segments divider within the Information 
Setup window 132 allows Segments to be created, modified, or deleted. A description of 
the segment appears in the Description field. Upon activation of button 801 by the user, 
the window 132 of Fig. 8B is launched, allowing the user to edit segment definitons. 

With reference to Fig. 9A, Measures of information may be created and 
modified within the Measures divider of the Information Setup window 132. A name for 
each Measure appears in the Measure Name Held. A definition of a Measure appears in 
the Definition field. Mathematical operators, Time Slice constraints, Segment constraints, 
and constraints from other Measures may be inserted into the Definition using the 
corresponding buttons below the Definition field. With respect to Figs. 9B and 9C, 
windows 132 may be displayed to select measures and select segments, respectively. 

With reference to Fig. 10, Measure relationships may be defined and 
modified within the Measure Relations divider of the Information Setup window 132. 
Measure relationships are defined in terms of an if-then statement. A primary measure and 
whether it increases or decreases is selected in the Measure field, which represents the u ir 
part of the If-Then statement. Measures within the Unrelated field may be moved to either 
the Decreases field or the Increases field to form the "Then" part of the If-Then statement. 
With respect to Fig. II, measure relationships may be restricted by means of the window 
132 of that figure. 

A batch of InfoFrames™ may be individually scheduled for automatic 
production. Scheduling of InfoFrames™ is particularly useful to those users that require 
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periodic InfoFrames™. InfoFrame™ time intervals may be selected under the Time 
Interval field, which provides daily, weekly, and monthly reporting options. 

With reference to Fig. 12, a sample InfoFrame™ is shown within Analysis 
window 136. The type of analysis performed is indicated in the InfoFrame™ and in the 
title bar as tt Change Analysis". The Segment (previously defined within the Segments 
divider of the Information Setup window 132) is "Store Ages Greater than 3 Years". The 
Measure (previously define within the Measures divider of the Information Setup window 
132) is "Same Store Sales". The Time Slice (previously defined in the Time Slice 
Considered fields of the Analyst Builder window 130) is "Year to date 1995 vs. Last 
Year". 

The InfoFrame™ provides a concise statement of changes that have occurred 
in the Primary Measure, Same Store Sales, and changes that have occurred in Measures 
related to the Same Store Sales, Stores Remodeled, and previously defined within the 
Measure Relations divider of the Information Setup window 132. The InfoFrame™ then 
contains an explanation, including a graph, for the change in the Primary Measure, Same 
Store Sales. 

InfoFrame™ may include multiple instances of HTML associated with a 
Measure, representing hyperlinks to text data or graphic data representing the results of the 
Measure. 

Turning now to Fig. 13, a method for creating Metadata™ 25 using client 
subsystem 12 is illustrated beginning with START 140. 

In step 141, the user specifies a Concept. 

In step 142, the user specifies one or more attributes for the Concept. 

In step 144, client subsystem 12 provides the user with the list of columns of 
tables in data warehouse 24. 

In step 146, the user maps every attribute to a column. The user can 
provide a textual description of the concepts and the attributes. 
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In step 148, the user specifies one or more indicators by "mapping" a 
Indicator to a column in a table within data warehouse 24. 

In step 150, client subsystem 12 provides the user with a list of columns for 
the purpose of mapping Indicators as well. 

In step 152, user selects an "aggregate method" for the Indicator that is 
mapped, which specifies how values for the Indicator are aggregated. The system supports 
the following aggregate methods: 

• Add 

• Average 

• Min 

• Max 

• Count 

• Last in period 

• First in period 

In step 154, the user selects the unit of measurement and specifies whether 
the Indicator is a currency. The user can optionally specify a plural form of the Indicator, 
a verb to describe change in the value of the Indicator, the precision for reporting the 
Indicator and a textual description of the Indicator. 

In step 156, client subsystem 12 ensures that tables having Indicator columns 
can be joined with tables that have Attribute columns. 

In step 158, client subsystem 12 determines whether the user wishes to enter 
additional Concepts. If so, the method returns to step 142. If not, the method ends at step 
160. 

The preceding description forms an overview of the present invention. The 
following sections describe the invention in further detail, broken into further sections. 
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2. CHent Subsystem » 

The client subsystem 12 is described in further detail below. 

Fig. 14 illustrates a more detailed block diagram of the client subsystem 12. 
Client subsystem 12 contains three subsystems: User Interface (UI) 1401, Manager 1402, 
and Server APIs 1403. As its name implies, the user interface subsystem 1401 allows the 
user 1 405 to interact with the client 12. At this level of detail f it can be seen that the User 
Interface subsystem 1401 uses services of both the Manager 1402 and the Server APIs 
1403; the Manager 1402 also uses services from the Server APIs 1403. The Server APIs 
subsystem 1403 provides high level APIs which abstract all client 12 interactions with the 
DAI subsystem 14. All communications between the client 12 and the DAI subsystem 14 
are sent through the Client Server Module (CSM) 1404, which is described in further detail 
below. 

Fig. 15 illustrates a block diagram of the client subsystem 12 having an 
increased level of detail over the block diagram of Fig. 14. The user interface subsystem 
1401 contains all portions of the program that are visible to the user 1405. Because this 
subsystem may be implemented as a standard MS-Windows style program, most of the 
units within the interface are either windows or dialog boxes. Each window or dialog box 
in the interface has one main class which defines its behavior, as detailed below. Some 
window or dialog classes also use other utility classes, which will also be defined below, 
where appropriate. 

The "top lever of control within the client subsystem 12 is the Application 
object 1511. The application object 151 1 is constructed automatically by the Microsoft 
Foundation Class (MFC) library's start-up code. The application object has two primary 
responsibilities: performing login validation, and displaying the main frame window. The 
frame window in a Multiple Document Interface (MDI) application owns the Menus, 
Toolbar, and Statusbar, and creates child window objects. 

The User Login process consists of two steps: getting a User Name and 
Password from the User, and sending them to the Connect function of the Server APIs 
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subsystem 1403. There are four possible results from an attempted Connect to the server 
32: 

• login succeeded 

• login failed 

• too many login failures 

• no response from server 32; network down 

Upon an unsuccessful login, the login dialog is re-displayed, and the user 
1405 may re-enter his/her name and/or password. After a certain number of unsuccessful 
attempts (number determined by server 32, not client 12), the server 32 will return the 
"too many failures" result, and the client 12 program will inform the user 1405 of this 
result, and then exit. If the network or server are down, the client 12 will start up in "off- 
line" mode, which allows the user 1405 to view saved InfoFrames™, but not to create or 
edit Analysts, or send InfoFrame™ generation requests. 

Upon a successful connect, the application will display the main frame 
window. A successful Connect result additionally returns an indication of whether the user 
1405 has Administrator (MDTA) privileges; if so, the frame window is informed, so that 
special menu items may be enabled. 

The Application object 1511 may make the following requests of other 

subsystems: 



Function Used 


Subsystem 


Connect 


Session Management API [Server APIs 
subsystem 1403/ 


Disconnect 


Session Management API /Server APIs 
subsystem 1403/ 


Display ManagerWindow 


Manager Window fUI subsystem 1401/ 



The Application object 151 1 is an instance of the clnt_App class. It creates 
one instance each of clnt_UserLoginDlg and dnt_Main Frame. 
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Class dnt_App is a subclass of the MFC class CWinApp. We inherit most 
of the standard behavior of the CWinApp, but override the Initlnstance function, in which 
we run the User Login process, and if successful, construct our main window, an instance 
of clnt_MainFrame. 

clnt_MainFrame is a subclass of MFC class CMDIFrameWnd. We override 
the OnCreate function, in order to initialize the Toolbar, and Menus, and to create the 
initial Manager Window instance 1512. 

The clnt_MainFrame instance handles some of the Menu and Toolbar 
requests, while others are handled by whichever Child Window is active (one of the four 
Manager Windows 1512 or the InfoFrame™ Viewer window 1517. as described below). 
The clntJvlainFrame instance is also responsible for enabling/disabling menu items that 
vary depending on which Child Window is active. 

The User Login dialog is controlled by an instance of the 
clnt_UserLoginDIg class, a subclass of the MFC class CDialog. The clntJJserLoginDlg 
instance displays a dialog which asks the User to enter a name and password. The name 
and password strings are returned to the calling function when the User clicks the -OK" 
button. 

The Toolbar is controlled by an instance of class clnt_Toolbar, a subclass of 
MFC's CToolBar. Class clnt_Toolbar inherits all functionality from CToolBar. and adds 
support for drag-and-drop. Instances of clnt_Toolbar accept drops of one Folder (onto 
Trash button), one or more Analysts (onto Trash. RunNow. or View buttons), and one or 
more InfoFrames™ (onto Trash, View, and Print buttons). 

The Information Definition 1515 includes all functionality related to 
addition, modification or deletion of Segments. Measures, and Measure Relationships. 

Three dialog boxes are used in the Information Definition 1515 process; one 
for each type of Information to be edited. The dialogs are controlled by instances of the 
following classes which are instantiated by clnt_MainFrame (in response to User requests 
through the Menu or Toolbar). 
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clnt BuiklMeasureP[g. This dialog allows the user to update or delete 
exisiting measure, or create a new Measure. 

clnt BuildSepmentPlfr. This dialog allows the user to update or delete 
exisiting segment, or create a new segment by defining attribute restrictions. 

Clnt ByildRcfrtiopnip,. This dialog allows the user to update or delete 
exisiting MeasureRelation, or define a new relationship. 

The Measure Relationship dialog uses the following services from other 

subsystems: 



Function Used 


Subsystem 


GetMeasureRelationship 


Metadata™ API [Server APIs subsystem 
1403] 


AddMeasureRelationship 


Metadata™ API [Server APIs subsystem 
14031 


DeJeteMeasureRelaiionship 


Metadata™ API [Server APIs subsystem 
14031 


UpdateMeasurcRclationsh ip 


Metadata™ API [Server A Pis subsystem 
14031 
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Function Used 


Subsystem 


AddMeasure 


Metadata™ API /Server APIs subsystem 
1403) 


DeleteMeasure 


Metadata™ API /Server APIs subsystem 
1403] 


UpdateMeasure 


Metadata™ API /Server APIs subsystem 
1403] 


GetAIIAnalysts 


Manager API /Manager APIs subsystem 
1402] 


The Segment dialog uses the following services: 


Function Used 


Subsystem 


Add Segment 


Metadata™ API /Server APIs subsystem 
1403) 


UpdateSegment 


Metadata™ API /Server APIs subsystem 
1403] 


DeleteSegment 


Metadata™ API (Server APIs subsystem 
1403] 


GetAIIAnalysts 


Manager API /Manager APIs subsystem 
1402] 



The Information Setup section 1515 is controlled by instances of the 
following classes: clntBuildRelationshipDlg, clnt_BuildMeasureDlg, 
clnt_BuildSegmentDIg and cInt_BuildRestrictDJg (ail subclasses of the MFC's CDialog). 
If the user 1405 selects to modify a private segment or measure, the clnt_MeasureDefDlg 
and clnt_SegmentDefDlg objects will be responsible for traversing through the list of 
existing Analysts and InfoFrames™ and if the segment or measure is found, the objects will 
take the following actions: 
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In case of Delete: 

• A message will be displayed to the User 1405 that deleting will cause some Analysts to 
no longer run correctly. The User 1405 will be presented with a list of Analysts that 
will be affected by this deletion. When an Analyst runs on a deleted segment or 
measure an error message will be returned. 

In case of Modify: 

• The newest segment/measure definition will always be used. The old definitions will 
be replaced. 

The User change requests will be transferred to DAI (through the Server APIs subsystem) 
for immediate update of the Metadata™. 

The Analyst Builder dialog box 1513 allows the User 1405 to select the 
parameters needed to generate a specific InfoFrame™ (see below). It also allows the User 
J 405 the option of Scheduling and/or defining Trigger conditions for an Analyst. To allow 
this to happen, the main Analyst dialog will prompt the User 1405 to complete a sequence 
of sub-dialogs; Measures, Segments, TimeSlice, Schedule, and Trigger. 

Other portions of the User Interface subsystem 1401 (i.e., Menus, Toolbar, 
or a Manager Window) invoke the Analyst Builder dialog 1513 either by passing it an 
existing Analyst object to view/edit, or by passing a NULL parameter, indicating that a 
new Analyst is to be created. 

The clnt_AnalystSheet dialog will instantiate a clnt_InfoFrameRequest object 
when the User 1405 requests to "Save" on a new Analyst or "Save As" on an existing 
Analyst. 
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The dnt_AnaJystSheet dialog makes the following requests to other 



subsystems: 



Function Used 


Subsystem 


NewAnalyst 


Manager API (Manager subsystem 1402] 


UpdateAnalvst 


Manager API [Manager subsystem 1402] 


RunAnaJystNow 


InfoFrame™ Generation API [Server APIs 
subsystem 14031 


SetFrameDefinition 


InfoFrameRequest API [Manager subsystem 
14021 


GetFrameDefmition 


InfoFrameRequest API {Manager subsystem 
1402/ 



The cInt_Ana]ystSheet class instantiates sub-dialogs of the following classes: 
clnt_Analy $ tMeasureP a ge. clnt.AnalystSegmcntPagc, clnt_AnaIystTimeSlicePage, 
clnt_AnalystSchedulePage, clnt_AnaIystTriggerPagc (all subclasses of MFC's 
CPropertyPage). These correspond to five panels within the main dialog box which the 
User 1405 will be led through in sequence. 

Also, the Analyst subsystem 1513 will use clnt_MetaTree class and 
cInt_Me auS reMap class which will provide access to the Metadate tables through 
Metadata 1 * 4 API's. 

The cln1_AnalystShcet subdialogs will be dynamically populated with the 
proper controls according to the User's 1405 selection of the Analyst type. The User input 
from the Dialog interfaces will be saved in a clnt_infoFrameRequcst object and returned to 
Manager subsystem to be saved (and submitted for scheduling, if a Schedule is present - 
see below regarding further details of the scheduler subsystem 18). 
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The cInt_AnaIystMeasurePage makes the following requests to the other 

subsystems: 



Function Used 


Subsystem 


GetName 


InfoFrameDefinition API /Manager subsystem 
1402] 


SetName 


InfoFrameDefinition API {Manager subsystem 
14021 


GetFrameType 


InfoFrameDefinition API [Manager subsystem 
14021 


SelFrameType 


InfoFrameDefinition API [Manager subsystem 
1402} 


GetTarget Measu re 


InfoFrameDefinition API [Manager subsystem 
J402J 


SetTargtMcasurc 


InfoFrameDefinition API [Manager subsystem 
1402] 


GetCompari son Measu re 


InfoFrameDefinition API [Manager subsystem 
1402} 


SetComparisonMcasurc 


InfoFrameDefinition API [Manager subsystem 
1402] 


GetAdditonaiMList 


InfoFrameDefinition API [Manager subsystem 
1402/ 


SetAdditionalMList 


InfoFrameDefinition API /Manager subsystem 
1402/ 



The chn_Ana]ystSegmentPage makes the following requests to other 

subsystems: 



Function Used 


Subsystem 


GetTargctSegment 


InfoFrameDefinition API [Manager subsystem 
14021 


SetTargetSegment 


InfoFrameDefinition API [Manager subsystem 
14021 


GetComparisonSegment 


InfoFrameDefinition API [Manager subsystem 
1402/ 


SetCornparisonSegment 


InfoFrameDefinition API [Manager subsystem 
1402/ 
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GetAdditionalSList 


InfoFrameDefinition API {Manager subsystem 
1402] 


SetAdditionalSList 


InfoFrameDefinition API [Manager subsystem 
1402] 


GetPartitionList 


InfoFrameDefinition API [Manager subsystem 
1402] 


SetPartitionList 


InfoFrameDefinition API (Manager subsystem 
1402] 


GetParentPartition 


InfoFrameDefinition API [Manager subsystem 
1402] 


GetParentPartition 


InfoFrameDefinition API [Manager subsystem 
1402] 



The clnt_AnalystTimeSIicePage makes the following requests to other 

subsystems: 



Function used 


Subsystem 


GetPeriodType 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


SetPeriodType 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


GetAnalysisType 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


SetAnalysisType 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


GetYearType 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


SetYearType 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


GelTrendlnterval 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


SetTrendlnterval 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


GetDuration 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


SetDuration 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


GetNurnDuration 


InfoFrameTimeSlice API [Manager subsystem 
1402] 
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SetNumDuration 


InfoFrameTimeSlice API /Manager subsystem 

I von i 

1402] 


GetBasePeriod 


InfoFrameTimeSHce API [Manager subsystem 
1402] 


SetBasePeriod 


InfoFrameTimeSlice API (Manager subsystem 
1402] 


GetBaseThmPeriod 


InfoFrameTimeShce API [Manager subsystem 
1402] 


SetBaseThruPeriod 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


GetCompPeriod 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


SelCompPeriod 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


Operator = 


InfoFrameTimeSlice API [Manager subsystem 
1402] 


GetTimeSIice 


InfoFrameDefinition API [Manager subsystem 
1402] 



The clnt_AnalystSchedulePage makes the following requests from other 

subsystems: 



Function 
GetNumlnterval 


Subsystem 

InfoFrameSchedule API (Manager subsystem 
1402] 


SetNumlnterval 


InfoFrameSchedule API [Manager subsystem 
1402] 


Getlnterval 


InfoFrameSchedule API [Manager subsystem 
1402] 


Setlnterval 


InfoFrameSchedule API [Manager subsystem 
1402] 


GetStartDate 


InfoFrameSchedule API [Manager subsystem 
1402] 


SetStartDate 


InfoFrameSchedule API [Manager subsystem 
1402] 


GelNumLimit 


InfoFrameSchedule API [Manager subsystem 
1402] 


SetNumLimit 


InfoFrameSchedule API [Manager subsystem 
1402] 
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Getlimit 


InfoFrameSchedule API [Manager subsystem 
1402] 


SeLLimil 


InfoFrameSchedule API [Manager subsystem 
1402] 


GetScheduIeFJag 


InfoFrameSchedule API [Manager subsystem 
1402] 


SetScheduIeFiag 


4, " wi laiHwuicuuic /manager suosystem 
1402] 


GetTriggerFlag 


InfoFrameSchedule API [Manager subsystem 
]402] 


SetTriggerFlag 


InfoFrameSchedule API [Manager subsystem 
1402] 


Operator = 


InfoFrameSchedule API [Manager subsystem 
1402/ 


SetSchedule 


InfoFrameReuest API [Manager subsystem 1402/ 



The clnt_AnalystTriggerPage makes the following requests from other 

subsystems: 



Function 


Subsystem 


GetTriggerList 
SetTriggerList 


InfoFrameTriRger API [Manager subsystem 1402/ 
InfoFrameTngger API [Manager subsystem 1402} 


GetMessageFlag 
SetMessageFlag 


InfoFrameTngger API [Manager subsystem 1402/ 
InfoFrameTngger API [Manager subsystem 1402} 


GetFrameFlag 
SetFrameFlag 


InfoFrameTngger API [Manager subsystem 14021 


GetAnalystList 
SetAniystList 


Update the state of the frame Generation action 
InfoFrameTngger API f Manager subsystem 1402/ 


Operator = 


InfoFrameTrigger API [Manager subsystem 1402 f 
InfoFrameTrigger API [Monaster subsystem 1402] 


GetMeasure 
SetMeasurc 
GetOperator 


Trigger API [Manager subsystem 14021 
Trigger API [Manager subsystem 14021 


SetOperator 
GetOperandl 


Trigger API [Manager subsystem 1402] 
Trigger API [Manager subsystem 14021 
Trigger API (Manager subsystem 14021 


GetOperand2 


Trigger API [Manager subsystem 1402] 


SetOperandi 
SetOperand2 
GetValuei 


Trigger API [Manager subwstem 14021 
Trigger API [Manager subsystem 1402] 
Trigger API [Manager subsystem 1402/ 
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GetVaIue2 


Trigger API [Manager subsystem 1402] 


SeiValuel 


Trigger API (Manager subsystem 14021 


SetValue2 


Trigger API [Manager subsystem 1402/ 


Operator = 


Trigger API /Manager subsystem J 402/ 


SetTrigger 


InfoFramcRequest API /Manager subsystem 
J402] 



The following is a list of user input requirements for each InfoFrame™ Type: 
(R = Required, O = Optional) 
c In t_Measu reDl g : 



Analysis Type 


Target 
Mcasu re 


Additional 
Measures 


Comparison 
Measure 


Change 


R 


0 




Segment 
Comparison 


R 


O 




Measure 
Comparison 


R 




R 


Summarization 


R 


O 




Trend 


R 


O 





dnt_SegmentDIg: 



Analysis Type 


Target 
Segment 


Additional 
Segments 


Comparison 
Segment 


Change 


R 


O 




Segment 
Comparison 


R 


O 


R 


Measure 
Comparison 


R 


O 




Summarization 


R 


O 




Trend 


R 


0 
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clmJTimeSliceDlg: 



Analysis Type 


Base Period 


Comparison 
Period 


Time Interval 


Change 


R 


R 




Segment 
Comparison 


R 






Measure 
Comparison 


R 






Summarization 


R 






Trend 


R 




R 



The InfoFrame™ Viewer Window 1517 displays an InfoFrame™ on screen 
(see below). In addition to displaying the InfoFrame™ data, the Viewer 1517 supports the 
"Drill Down" capability by presenting hot spot: to the User 1405, and generating the 
appropriate requests when a hot spot is selected. The InfoFrame™ Viewer also gives the 
User a capability to Annotate an InfoFrame™. 

When InfoFrame™ Viewer 1517 is created, it receives the name of the 
InfoFrame™ file and a pointer to the InfoFrame™ object. This data is parsed (further 
processing is also done, including generating graphs from embedded data), then displayed. 

The Parser capability within the InfoFrame™ Viewer module 1517 is also 
used for the SaveAs requests; the raw InfoFrame™ data is translated to standard HTML 
data (i.e., MDT-specific graph data is translated into a graphical image in a standard 
format), and is written to a file in either ASCII or Unicode characters. The InfoFrame™ 
Viewer Window 1517 also supports the InfoFrame™ Print function. This functionality is 
built on the capabilities provided by the CDocumcnt and CScrollView classes of MFC. 
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The InfoFrame™ Viewer subsystem 1517 makes the following requests to 
other subsystems. 



Function Used 


SubSyslem 


UpdatelnfoFrarne™ 


Manager API {Manager subsystem 1402] 


DrillDown 


Manager API [Manager subsystem 1402] 



Parser: the clnt_Parser class provides the HTML parsing capability for the 
Client 12 through the following three functions: 



Service Provided 


Description 


doParse 


Called by the InfoFrame™ Viewer, this function 
parses the given HTML data, and returns a list of 
clnt_Tag objects, each representing an element of 
the HTML Data. The cintJTag objects can contain 
lists of sub-Tags, so that nesting is preserved. 


SaveAsHTMLJJnicode 


Called by the Manager 1402 when the User 1405 
requests to Save an HTML file. Parses the HTML 
data to replace any non-standard HTML elements 
with standard HTML data (for example, raw graph 
data must be transformed into a graphic image). 
Writes transformed data into a file, using Unicode 
characters. 


SaveAsHTML_ASCII 


Same as above, except characters are written out as 
ASCII. 



Viewer: the Viewer is implemented using the MFC Document/View 
architecture. Class cInt_Viewer is a subclass of CScrollView (MFC), which provides the 
automatic scrolling. Class clnt_ParserDoc is a subclass of CDocument On creation, it 
instantiates a clnt_Parser object id parse the HTML Data. The clnt_Viewer then traverses 
the relumed list of cintJTag objects and places their visual representations in the Window. 
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The following collection of controls are used by the user interface subsystem 

J401: 

clnt TreeCtrl. All dialog controls which will be representing segments 
and/or partitions inherit from this class rather than from the MFC's CTreeCtrl. 
clnt_MetaTree control also inherits from this class. 

clnt MetaTree. This control is used to represent the Metadata™ segments 
and partitions in a hirerchical format. The following dialogs subclass this control: 
clnt_AnalystSegmcntPage, c!nt_BuildSegmentDlg, cInt_RestrictMeasureDlg. 

clnt TopL evelSegmentCombo . This conttrol is used to represent all 
Metadata™ top level segments in a DropDown ComboBox. The following dialogs subclass 
this control: dnt_Ana]ystSegmentPage, clnt_BuildSegmentDlg, clnt_RestrictMeasureDlg. 

clnt DurationCombo. This control represents the user's conditional 
operator choices in a dropdown combobox format. The following dialogs subclass this 
control: clnt^AnalystPeriodPage, clnt_AnalystSchedulePage. 

clnt QperatorCombo. This control represents the user's conditional 
operator choices in a dropdown combobox format. The following dialogs subclass this 
control: clnt_AnalystPeriodPage, clnt^AnalystSchedulePage. 

rtnt_DateEdn. This control is used to represent the locale date. It validates 
the user entry and formats the date properly for the locale. The following dialogs subclass 
this control: clnt_AnalystPeriodPage, clnt_AnalystSchedulePage. 

lnt ReadOnlvListBox. This control is used for a non-select listbox. There 
is no dependencies from other subsystems. The following dialog subclasses this control: 
clnt_Bui!dSegmentDlg 
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Function Used 


Subsystem 


GetSegment 


Metadata™ API [Server APIs subsystem 
1403] 


GetPartition 


Metadata™ API [Server APIs subsystem 
1403] 



The clnt_TopLevelSegmentCombo uses the following services from other subsystems: 



Function Used 


Subsystem 


GetSegment 


Metadata™ API [Server APIs subsystem 
1403] 



The clnt_MeasureCombo uses the following services from other subsystems: 



Function Used 


SubSystem 


GetBasicMeasure 


Metadata™ API [Server APIs subsystem 
1403] 


GetCompositeMeasure 


Metadata™ API [Server APIs subsystem 
1403] 



The Administrator Interface 1516 consists of two tasks: User Account setup, 
and Metadata™ Builder. The User Accounts setup dialog allows the MDTA 
(Administrator) to create and manager User accounts, including login name, password, and 
User type. The Metadata™ Builder allows the MDTA to define Dimensions, Attributes, 
and Basic Measures, to create Segments, map columns for Time values, and define Year 
types. 

The User Accounts screen utilizes the clnMJserLogin class from the Server 
APIs subsystem 1403. The Metadata™ Builder screens utilize nearly all Metadata™ 
functions provided by the Server APIs subsystem 1403. This includes the services of 
classes clnt_Communications, clnt_Dimension, clnt_Attribute, clntJBasicMeasure, and 
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clnt_Segment. It also uses the clnt_Schema class for access to the Data Warehouse 
schema. 

The User Accounts dialog is controlled by an instance of 
clnt_UserAccountsDlg, a subclass of MFC's CDialog. The interface that 
clnt JJserAccountsDlg presents to the rest of the system is the standard for CDialog 
objects; the instance is constructed, and then DoModalO is called to display the dialog. 
The call to DoModalO returns only when the User 1405 presses the "Cancel" or "Close" 
button. 

The Metadata™ Builder dialog may be a "wizard" style dialog, meaning that 
it presents a series of sub-dialogs in a pre-determined order. The User 1405 may press the 
"Next" and "Back" buttons to traverse the list of sub-dialogs, and may press "Cancer to 
exit from the Metadata™ Builder. The "frame" of the wizard is implemented by class 
clnt^MasterSetup, which is a subclass of MFC's CP roperty Sheet. The constructor of 
clnt_MasterSetup creates one instance each of the dialog "pages" (clnt_AttributeDefinition, 
cinr_AttributeMapping, clnt_AttributeValueDeflnition, clnt^AutomaticSegments, 
clnt_BasicMeasureDefinition, clntJBasicMeasureMap, clnt_DimensionDefinition, 
clnt_Joins, clnl_TimeDimension, clnt_YearDefinition). The pages are loaded into the 
"wizard" automatically when it is displayed. This is transparent to the rest of the Client 
application 12, which simply constructs the Metadata™ Builder and calls DoModalO on the 
instance. 

Each of the "pages" loads its initial display data through calls to the 
ServerAPIs 1403 Metadata™ classes, and each page responds to the "Save" button by 
updating its data through the ServerAPIs 1403. 

The clnt_MasterSetup has one linked list for each type of Metadata™ used. 
Each list contains zero or more cintSetupObject objects. The clnt_SetupObject object 
contains two data members: one pointer to a CObject and one clnt_ObjectState 
enumeration. clnt_ObjectState can take on one of four values: STATE_EXI STING , 
STATE_NEW, STATE_DELETED, STATE_MODIFIED. These linked lists are available 
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to every "wizard" page. Every time the user 1405 adds, deletes or modifies a Metadata 1 " 
object, it is added to the appropriate linked list. These linked lists are used to determine 
which objects to display to the user 1405 and which ones to hide from the user 1405, The 
linked lists are also used by the "CANCEL" and "SAVE" buttons. When the user 1405 
presses the "CANCEL" button, all objects in the linked lists are deleted. When the user 
1405 presses the "SAVE" button, all objects in the linked lists axe accessed. If the Yaluc of 
the enumeration is STATE_EXIST1NG the object is deleted from the list. If the value is 
STATE_NEW the object is added to the Metadata™ on the server and deleted from the list. 
If the value is STATE_D ELETED the object is deleted from the Metadata™ on the server 
and the object is deleted from the list. If the value is STAT_MODIFIED the object is 
updated in the Metadata™ on the server and the object is deleted from the list. 

The "SAVE" button on the "wizard" page adds, deletes and modifies 
objects in a certain order. For deleting objects, the following table lists the object to be 
deleted in the left column and the associated objects in the right column that will be deleted 
from the linked lists on the Client 12 if they exist. The row order in the left column defines 
which object will be deleted, added or modified first. Dimensions would be added first 
and Year Definitions would be added last. 



Object Associated objects 



Dimension 


Attribute, Segment 


Attribute 


Enumerate Attribute Value, Restricted Integer Attribute, 
Restricted Float Attribute, Segment, Attribute Measure 
Join, Attribute Attribute Join 


Enumerated Attribute Value 


< none> 


Restricted Integer Attribute 


< none> 


Restricted Float Attribute 


< nonc> 


Segment 


Numerical Attribute Restriction 


Numerical Attribute Restriction 


<nonc> 


Enumerate String Attribute 
Restriction 


<none> 
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Partition 


<none> 


Basic Measure 


Attribute Measure Join 


Composite Measure 


Constant, Segment List, Attribute Measure Join 


Constant 


<none> 


Segment List 


<none> 


Attribute Measure Join 


<none> 


Attribute Attribute Join 


<none> 


Measure Relationship 


Measure Relation Range Restriction, Measure Relation 
Magnitude Restriction, Measure Relation Segment 
Constraint 


Measure Relation Range 
Restriction 


<none> 


Measure Relation Magnitude 


< none> 


Measure Relation Segment 
Constraint 


<none> 


Time Definition 


<none> 


Time Mapping 


< none> 


Year Definition 


< none> 



When the user deletes an object that already exist in the Metadata™ 25 on the server 34, 
just that object is deleted. The "associated objects" for that object will be deleted by the 
DAI subsystem 14. 

The Manager Windows 1512 give the User 1405 access to all types of data 
which are stored by the Manager subsystem 1402: Folders, Analysts, and InfoFrames™, as 
well as information about Pending InfoFrames™. 

There are four types of Manager Windows 1512, each offering a different 
view of this data: 

• Analyst list (flat list of all Analysts) 

• InfoFrame™ list (flat list of all InfoFrames™) 

• Folder View (includes Folder hierarchy; shows InfoFrames™ & Analysts in 
current Folder) 

• Pending Queue (flat list of InfoFrames™ pending in the DAI 14). 
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Note that the Pending Queue window is included with the other three 
Manager Windows because of its similarity in construction and interface behavior; the data 
it displays is actually quite distinct from that of the other three Windows. 

Drag-and-Drop features are also supported by the Manager Windows 1512. 
The Analyst list, InfoFrame™ list, and Folder View can be the source of a "drag" 
operation (Users may drag one Folder, one or more Analysts, or one or more 
InfoFrames™). The Folder View may also be the destination of a "drag" operation. 

The first three Manager Window types (Analyst list, InfoFrame™ list, 
Folder view) use the following services from other subsystems: 



Function Used 


SubSystcni 


GetRootFolder 


Manager API [Manager subsystem 1402] 


GetTrashBin 


Manager API [Manager subsystem 1402] 


GetAlIAnalysts 


Manager API [Manager subsystem 1402] 


GetAllInfoFrames™ 


Manager API [Manager subsystem 1402) 


NewFolder 


Manager API [Manager subsystem 1402] 


RemovcFolder 


Manager API [Manager subsystem 1402] 


MoveFolder 


Manager API [Manager subsystem 1402] 


SetFolderName 


Manager API [Manager subsystem 1402) 


MoveAnalyst 


Manager API [Manager subsystem 1402] 


RernoveAnalyst 


Manager API [Manager subsystem 1402] 


MovelnfoFrarne™ 


Manager API [Manager subsystem 1402] 


Re moveln foFrame™ 


Manager API [Manager subsystem 1402] 


EmptyTrash 


Manager API [Manager subsystem 1402] 


GetChildFolders 


Folder API [Manager subsystem 1402/ 


GetlnfoFrames™ 


Folder API [Manager subsystem 1402] 


GetAnalysts 


Folder API [Manager subsystem 1402] 


RemoveFolder 


Folder API [Manager subsystem 1402] 


Run Anal yslNow 


InfoFrame™ Generation API [Server API 
subsystem 1403] 


ViewInfoFrame™ 


InfoFrame™ Viewer Window [User Interface 
suljsystem 1401] 


run AnalystBuilder dialog 


Analyst Builder [User Interface subsystem 1401] 
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The fourth Manager Window, Pending Queue, uses the following services from other 
subsystems: 



Function Used 


SubSystem 


GetStatus 


InfoFrame™ Generation API [Server API 
subsystem 1403] 


Cancel Analyst 


InfoFrame™ Generation API [Server API 
subsystem 1403} 



Each of the four Manager Windows 1512 is controlled by a frame object and 
one or more control objects placed within the frame. In all four cases, the frame is 
represented by just one class, clnt_ManagerWnd, a subclass of CMDIChildWnd from 
MFC. The clnt_ManagerWnd object is parameterized on instantiation to indicate which 
control object(s) it should construct. As the superclass would suggest, it behaves as a 
standard MDI Child Window. 

The control objects within the frame window inherit from MFC classes 
which are, in turn, wrappers for standard MS-Windows Controls. Classes 
clnt_AnaIystCtrl, clntJnfoFrameCtrl, and clntJPendingCtrl each inherit from CListCtri, 
and display their data in "columned" lists. Class clnt_FolderCtrl inherits from CTreeCtrl 
to display the tree-like hierarchy of the MDT Folders. These classes are instantiated, as 
needed, by the dnt_ManagerWnd, depending on the "style" flag it receives: 
clnt_AnalystCtrI is used in ANALYSTS mode and FOLDERS mode; clntJnfoFrameCtrl is 
used in INFOFRAMES and FOLDERS modes; clnt_FolderCtrl is used in FOLDERS mode 
and by the clnt_SaveAs dialog box (a part of the Analyst Builder); clntJPendingCtrl is used 
in PENDING mode. 

When the User 1405 begins a drag-and-drop operation, the source window 
of the drag constructs an instance of clntJDragWnd, which then controls the remainder of 
the drag-and-drop. The clnt_DragWnd is given a pointer to the object or list of objects 
being dragged, and also an indication of the type of object being dragged. It then sends a 
message to any window the cursor passes over, asking whether it is "OK" to drop the 
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object in that window. The windows which support drops arc clntJFolderCtrl and 
clnt_TooIbar (sec section 3.2.3). When the User 1405 releases the mouse 21 button, the 
clntJDragWnd sends a message to the destination window requesting it to accept the 
dropped item(s), and also sends a message to the source window indicating that the drop 
was completed. 

The Manager subsystem 1402 handles all functions related to manipulating, 
storing, and retrieving Folder 100 hierarchies, and the InfoFrames™ and Analysts that are 
stored in those Folders. Because all functions related to storing and retrieving this data are 
encapsulated in ihe Manager subsystem 1402, there will be minimal impact on the other 
Client subsystems if the Folders/InfoFrames™/ Analysts data store moves onto the Server 
tier 32 in an alternate embodiment of the present invention. 

As can be seen Fig. 15, the Manager 1402 provides four APIs: Manager 
1521, Folder 1522, Analyst 1523, and InfoFrame™ 1524. These APIs correspond to four 
classes which are described in the following sections. The main class in the Manager 
subsystem 1521 is the clnt_Manager class. Three data object classes: cint_Folder, 
clntJnfoFrameRequest, and cln ^InfoFrame™, are used by the clnt_Manager, and by other 
subsystems. Access to Manager functions normally begins with a call to the clnt_Manager 
itself, requesting a list of Folders, Analysts, or InfoFrames™. The objects which are 
returned by these queries can then be displayed to the User 1405 for viewing and/or 
manipulating. Requests for changes to any of the data objects pass through the 
clnt_Manager, which handles storing the changes on disk and, as applicable, sending the 
changes to the Server API subsystem 1403. 

The Manager subsystem .1402 also provides a "TrashBin" capability; that is, 
when a request to delete an Analyst or an InfoFrame™ is received, the object is placed in 
the TrashBin, and not actually deleted until the next Empty Trash command is received. 
The TrashBin is persistent between sessions of the Client 12. The TrashBin is 
implemented as an instance of the clntJFolder class. 
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There is exactly one instance 1521 of the clnt_Manager class in the Client 
application 12. In order to ensure that only one instance will be created, and that it will be 
safely globally available, the class uses the "Singleton" design pattern (as described in 
Gamma, et aL, Design Pat terns: Elements of Reusable Object -Oriented Software , 
Addison-Wesley, 1995, ISBN 0-201-63361-2). In this pattern, the class provides a static 
member function which returns a pointer to the one instance of itself. The function 
automatically creates the instance the first time it is called. The constructor of the class is 
made protected, thus ensuring that the class is never instantiated elsewhere. 

The clntjvlanager class handles the following requests from other 

subsystems: 



Service Provided 


Description 


GetManager 


Static class function which returns a pointer to the 
one instance of clnt Manager. Sec above. 


GetRootFolder 


Returns pointer to top clnt Folder object. 


GetTrashBin 


Returns pointer to TrashBin (actually a clnt_Folder 
object). 


GetAUAnalysts 


Returns a list of all Analysts, without regard to 
Folder hierarchy. 


GetAllInfoFrames™ 


Returns a list of all InfoFrames™, without regard 
to Folder hierarchy. 


NewFolder 


Creates a new Folder; parameter indicates the 
parent for the new Folder; returns pointer to the 
newly-created clnt- Folder object. 


RemoveFoider 


Removes the given clnt_Folder object; all of its 
sub-folders, Analysts, and InfoFrarnes™ are also 
removed. 


MoveFolder 


Moves the given Folder to a new Parent Folder. 


NewAnalyst 


Stores a new clntJtofoFrameRequest object in the 
given Folder, sends to Schedule Analyst Server 
API, if a Schedule is present. 


UpdatcAnalyst 


Stores changes to an existing 
clnt_InfoFrameRequest object, sends to 
UpdateAnalyst Server API, if a Schedule is 
present. 
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MoveAnalyst 


Moves clnt_InfoFrameRequest object to a different 
Folder. 


RemoveAnalyst 


Deletes the given clnt_InfoFrameRequest object; if 
a Schedule is present, sends a CancelAnalyst to the 
Server API subsystem. 


UpdatelnfoFrarne™ 


Stores changes to an existing clnt_InfoFrame™ 
object (normally changes to its HTML data, when 
annotations are added or raw data is processed into 
a graph, for example). 


Movel n foFrame™ 


Moves the given clnMnfoFrame™ object to a 
different Folder. 


Rem o vel n f oFra mc™ 


Deletes the given clnt InfoFrame™ object. 


DrillDown 


If requested DrillDown Frame is already generated, 
returns that Frame; if not, sends the Frame 
Generation request to Server API. 


SavelnfoFrameAsMDTF 
ilc 


Creates a file that can be e-mailed, etc. File is an 
"MDT InfoFrame™ File"— only useable by 
someone who has Client software 12. 


Saveln foFrameAsHTML 
File 


Creates a file that can be e-mailed, etc. File is a 
standard HTML 3.0 file, viewable by any HTML 
Browser program. A parameter to the function 
indicates if ASCII or UNICODE output was 
requested by the User. 


ImportMDTFile 


Reads in a File previously created by 
Saveln foFrameAsMDTFile command, stores it as 
an InfoFrame™ object in a Folder. The 
InfoFrame™ is then available for viewing through 
standard mechanisms. 


EmptyTrash 


Completely deletes all items currently in the 
TrashBin. 



60 



(188) 



»BB¥ 1 0-20775 1 



The clnt_Manager object uses the following services from other subsystems: 



Function Used 


Subsystem 


Schedule Analyst 


Analyst API [Server API subsystem 1403/ 


UpdaleAnalyst 


Analyst API [Server API subsystem 1403] 


CancelAnalyst 


Analyst API [Server API subsystem 1403] 


GetStatus 


lnfoFrame™ Generation API [Server API 
subsystem 1403} 


RetrieveFrame 


lnfoFrame™ Generation API [Server API 
subsystem 1403] 



Instances 1522 of class clnt_Folder are instantiated and deleted only by the 
clnt_Manager object. Other subsystems gain access to clntJFolder instances starting with 
the dnt_Manager*s GetRootFolder() or GetTrashBinO functions. 

The clnt_Folder object handles the following requests from other 

subsystems: 



Service Provided 


Description 


GetFolderName 


Returns name of this Folder. 


SetFolderName 


Changes the name of this Folder. 


GetChildFolders 


Returns a list of clnt_Folder objects which are 
"children" of this Folder. 


GetlnfoFrames™ 


Returns a list of clnt_InfoFramc™ objects which 
are stored in this Folder. 


GetAnalysts 


Returns a list of clnt_InfoFrameRcquest objects 
which are stored in this Folder. 


RemoveFolder 


Removes the given clnt_Fo3der object; all of its 
sub-folders, Analysts, and InfoFrarnes™ are also 
removed. 



Instances 1523 of class clnt_InfoFrameRequest are created by the 
clntjvfanager object (when restoring saved Analysts from disk) and by the 
clnt_AnalystBuilder dialog class (when creating a new Analyst or doing a Save As on a 
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current Analyst). Other subsystems normally access Analyst objects by retrieving them 
from their Folder (clnt_FoIder::GetAnalystsO). Instances of clnt_InfoFramcRequest arc 
only deleted by the c!nt_Manager object. 

The clnt_infoFrameRequest class handles the following requests from other 

subsystems: 



Service Provided 


Description 


GetName 


Returns name of this Analyst. 


SetName 


Assigns a new name for this Analyst. 


GctRequestID 


Return a unique request ID assigned by Manager 


SetRequestID 


Assigns a unique request ID to the Analyst 
Request 


GetUserName 


Returns the user name 


SetUserName 


Assigns a user name to the Analyst Request 


GetFrameDef 


Returns the clnt_InfoFrameDeftnition object for 
this Analyst. 


SetFrameDef 


Updates the Analyst's FrameDefinition object. 


GetSchedule 


Returns the clnt Schedule object for this Analyst. 


SetSchedule 


Updates the Analyst's Schedule object. 


GetTrigger 


Returns the clnt Trigger object for this Analyst. 


SetTrigger 


Updates the Analyst's Trigger object. 


GetContaining Folder 


Returns the pointer to the containig foldr object 


SetContainingFolder 


Updates the pointer to the containing folder object 



The clnt_InfoFrameRequest class does most of its work through three helper 
classes. The clnt_Info FrameDefinition class stores a description of the InfoFrame™ 
Generation request that will be sent when this Analyst is run (or scheduled). 

The clnt_infoFrameDefinition class handles the following requests from 
other subsystems 



Service Provided 


Description 


GetFolderlD 


Return the Folder ID assign to the analyst by 
clnt Folder object 


SeiFoIderlD 


Assigns the Folder ID to the Analyst. 
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GetAnalysisType 


Returns the type of analysis Selected for this 
request 


SetAnalysisType 


Updates the type of analysis selected for this 
request 


GctTargct Mcas u rc 


Returns the target measure selected for this 
analysis. Required 


SetTargetMeasure 


Urxlates the tareet measure ^ele£tf*rl fnr thi* 

vjn>a»V4 »iivi O 4 w-c* j ^ ablVvlvU i \Ji Lilt) 

analysis. Required. 


GetCompari sonMeasure 


Returns the comnarisnn Mmciit*^ vlf^t^H fnr thic 
analysis. Required only for Measure Compariosn 
Anal vite 


SctComparison Measure 


Updates the Compariosn Meausre Selected for this 
Comparison Analysis 


GetAdditionnlMList 


Returns a list of Additional measure Objects 

^ju-c-LUAi iur iius analysis, v/pilurlal* 


SctAdditionalMList 


Updates the List of Additional measure Objects 
sleeted for this analysis. Optional 


GetXar PctS p & rn rn t 


jvciums me largei segment selected lor this 
analysis. Required 


SetTarPet^epmpnt 


upaaies me larger, oegmcnt selected tor this 
analysis. Required. 


{"jPtComruiri v»n ^ppmpnt 


ivciums me comparison jsegmeni selectee tor tnis 
analysis. Required only for Segment Compariosn 

A na 1 vcic 


SetComparisonSegment 


Updates the Compariosn Segment Selected for this 
oiiojyxiii. i\ca^u ii cxi oniy ior ocgmcni 
Comparison Analysis 


GetAdditionalSList 


Returns a list of Additional measure Objects 
selecied for this analysis. Optional. 


SetAdditionaJSList 


Updates the List of Additional Segment Objects 
sleeted for this analysis. Optional 


GetParti Lion List 


Returns the List of selected target Partitions. 
Optional. 


SetPartitionList 


Updates the List of selected target Partitions. 
Optional. 


G etParen t Parti t i on 


Returns the target segment's parent partition. 
Required only if target segment is not top level 
segment. | 
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SetParen (Partition 


Updates the target segment's parent partition. 
Required onJy if target segmetn is not top level 
segment. 


GetTimeSlice 


Returns the pointer to the timeslice object for this 
analysis Required. 


SetTimeSiicc 


Updates the pointer to the timeslice object for this 
analyusis. Required. 


Operator = 


Copies the object into another 
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The clnt_InfoFrameTimeSlice class handles the following requests from 
other subsystems: 



Service Provided 


Description 


GetPeriodType 


Returns the type of timeslice selected for the 
request. 


SetPeriodType 


Updates the type of timeslice selected for the 
request. 


Get Anal ysisType 


Returns the type of analysis selected for the 
request. 


SetAnalysisType 


Updates the type of analysis selected for the 
request. 


GetYearType 


Returns the type of year definition selected for the 
request 


SetYearType 


Updates the type of year definition selected for the 
request 


GetTrendlnterval 


Returns the interval duration. Required only for 
Trend Analysis. 


SetTrendlnterval 


Updates the interval duration. Reuired only for 
Trend Analysis. 


GetDuration 


Returns the time duration. 


SetDuration 


Updates the time duration. 


GetNumDu ration 


Returns the number of durations. 


SetNumDuration 


Updates the number of durations. 


GeEBasePeriod 


Returns the Specific Date's base period. 


SetBasePeriod 


Updates the Specific Date's base period. 


GetBaseThruPeriod 


Returns the Specific Date's thru period. 


SetBaseThruPeriod 


Updates the Specific Date's thru period. 


GetCompPeriod 


Returns the Specific Date's Comparison Period. 
Required only by Change Analysis. 


SetCompPeriod 


Updates the Specific Date's Comparison Period. 
Required only by Change Analysis. 


Operator^ 


Copies one TimeSlice object inot another. 
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Analyst. 



The clnt_infoFrameSchedule class handles the following requests from other subsystems: 



Service Provided 


Description 


GetNumlnferval 


Return Number of intervals the report should run. 


SetNumlntcrval 


Update the number of intervals the report should 
run. 


Getlnterval 


Return the duration for the interval the report 
should run. 


Setlnterval 


Updates the duration for the interval the report 
should run. 


GetStartDate 


Rutun the date to which the report is scheduled to 
start runing. 


SetStartDate 


Updates the date to which the report is scheduled 
to start running. 


GetNumLimit 


Retuns the number of time periods the reports is 
scheduled to run. 


SetNumLimit 


Updates the number of time periods the report os 
scheduled to run, 


GetLimit 


Return the duration for the number of times the 
report is scheduled to run. 


SelLimit 


Updates the duration for the number of times the 
report is scheduled to run. 


GetScheduleFlag 


Returns the enabling or disabling state of the 
schedule. 


SetScheduleFiag 


Updates the enabling or disabling state of the 
schedule. 


GetTriggerFlag 


Returns the enabling or disabling state of the 
trigger definition. 


SetTriggerFiag 


Updates the enabling or disabling state of the 
trigger definition. 


Operate r= 


Copies one Schedule object into another 
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The clntJtafoFrameTrigger class handles definition of trigger conditions to 
be checked before the Analyst is run. The clntJnfoFrameTrigger class handles the 
following requests from other subsystems: 



Service Provided 


Description 


GetTriggerList 


Return a list of triggers defined by the analyst 


SetTriggcrList 


\j i /vjci iv-o « iiji vi niggers uciinco uy inc analyst 


GetMessageFlag 


Return the enable/disable state depending on user 
selection of the action to be taken. In this case a 
message will be generated if trigger becomes true. 


SetMcssageFlag 


Update the state of the message generation action. 


GetFrarncFiag 


Return the enable/disable slate depending on user 
selection of the action to be taken. In this case a 
Frame will be generated if trigger becomes true. 


SetFrameFlag 


Update the state of the frame generation action 


GetAnalystList 


Return a list of analysts to be generated if the 
trigger becomes true. If List empty, this action is 
not selected. 


SetAnlystList 


Update the list of analyst to be generated if the 
trigger becomes true. If List empty , this action is 
not selected 


Operator = 


Copies the object into another 



The class clnt trigger contains a single trigger condition. A list of 
clnt_trigger objects will be ANDed and defined as a single trigger. The clntJTrigger class 
handles the following requests from other subsystems: 



Service Provided 


Description 


GetMeasure 


Returns the measure selected. 


SetMeasure 


Updates the measure seleceted 


GetOperator 


Returns the operator selected 


SetOperator 


Updates the operator selected 


GetOperandl 


Returns the first operand measure 


GetOperand2 


Returns the second operand measure if operator is 
Between or not Between. 
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SetOperandl 


Updates the first operand measure 


SctOperand2 


Updates the second operand measure if operator is 
Between or not Between. 


GetValue) 


Returns the first operand value 


GetVaIue2 


Returns the second operand value 


SetValuel 


Update the first operand value 


SetValue2 


Updates the second operand value, if Operator is 
Between or not Between. 


Operator = 


Copies the object into another 



Each instance 1523 of clntlnfoFrameRequest must have a 
clntJnfoFrameDeftnition object; the clntJnfoFrameSchedule and clntJTrigger objects are 
optional. 

Instances 1524 of class clnt_InfoFrame™ are instantiated by the 
clntjvlanager object (when restoring saved Analysts from disk or receiving a new Frame 
from the Server API). Other subsystems normally access InfoFrame™ objects by 
retrieving them from their Folder (clnt_Folder::GetInfoFrames™ 0). Instances of 
clnt_InfoFrame™ are only deleted by the clnt_Manager object. 

The clnt_InfoFrame™ class handles the following requests from other 

subsystems: 



Service Provided 


Description 


GetName 


Returns name of this InfoFrame™. 


GeiHTMLFile 


Returns name of file containing HTML Frame 
data is stored. 


UpdateHTMLFile 


Informs InfoFrame™ that it's data file has been 
updated (may be required for annotation, drill- 
down, graph generation). 



The Server API subsystem 1403 encapsulates all functions which require 
communication with the MDT Server 32 (DAI 14). This isolates the User Interface 1401 
and Folder Manager 1402 subsystems from specific knowledge about the Client-Server 
interface, keeping them independent of minor changes, etc. 



68 



(196) 



0-2 077 5 1 



As seen in Fig. 15, the Server APIs 1403 can be divided into four API 
modules: Metadata™ 1531 , InfoFrame™ Generation 1532, Data Warehouse 1533, and 
Session Management 1534. The Server APIs subsystem 1403 also includes a set of 
internal routines for talking to the CSM 1404, which are shared by the four APIs. Each 
module is described below. 

The Metadata™ API 1531 handles all Client 12 requests to view or modify 
portions of the MDT Metadata™ 25. Again the Metadata™ 25 resides on the server 34, 
and the Client 12 retrieves pieces of the Metadata™ 25 as needed, via the DAI 14. 

The Metadata™ API 1531 provides the following services to other Client 

subsystems: 



Service Provided 


Description 


GetDimensions 


Returns a list of clnt_Dimension objects 
representing all Dimensions. 


AddDimension 


Add a new Dimension. 


UpdatcDimcnsion 


Update an existing Dimension. 


DeleteDimension 


Remove an existing Dimension. 


GetDimensionPartitions 


Returns a list of cln£_Partition objects for all 
Child Partitions within a given Dimension. 


GetPartitions 


Returns a list of clnt_Partition objects for all 
Child Partitions within a given Segment. 


AddPartition 


Add a new Partition. 


UpdatePartilion 


Update an existing Partition. 


DeletePartition 


Remove an existing Partition. 


GetSegments 


Returns a list of clnt_Segment objects for all 
defined Segments within a given Partition. 


AddSegrnent 


Add a new Segment. 


UpdateS eg men I 


Update an existing Segment. 


DeleteSegment 


Remove an existing Segment. 


GetMeasures 


Returns 3 lists: Basic Measures, Composite 
Measures, and all Measures which are 
accessible to the User (some Measures are 
used internally in the Client code). 


AddMeasuTe 


Add a new Measure. 


UpdateMeasure 


Modify an existing Measure. 
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DeletcMcasure 


Remove an existing Measure. 


GetMcasureRelationship 


Retrieve a Measure Relationship. 


AddMeasurcRelationship 


Add a new Measure Relationship. 


UpdatcMeasureRelationship 


Update an existing Measure Relationship. 


DcJcteMcasureRelationship 


Remove an existing Measure Relationship. 


GetRelationships 


Retrieve possible Relationship types for a 
given Attribute. 


GctRange 


Retrieve range of values for a given Attribute. 



The Metadata™ API uses the Communications Services module (see below) 
to communicate with the CSM 1404. 

Several classes work together to provide the set of services listed in the table 
above. Class dnt_Dimension has public methods: GetDimensions (a static class method), 
AddDimension, UpdateDirnension, DeleteDirnension, and GetDimensionPartitions, 
AddDimensionPartition, DeieteDimensionPartition. Class clnt_Partition has public 
methods: GetSegments, AddSegment, DeleteSegment, UpdatePartition. Class 
clnt Segment has public methods: GetPartitions, AddPartition, DeletePartition, 
UpdateSegment. Measure functions are represented by two classes: clnt_BasicMeasure and 
clnt_CompositeMeasure. 

The InfoFrame™ Generation API 1532 contains all functions related to 
requesting that the DAI 14 run or schedule an Analyst, and retrieving status and completed 
InfoFrames™ from the DAI 14. Functions in this API 1532 are used by the Manager 
subsystem 1402 and the User Interface subsystem 1401. 

The InfoFrame™ Generation API 1532 provides the following services to 
other Client subsystems: 



Service Provided 


Description 


GetlnfoFrameGenerationlnst 
ance 


Returns a pointer to the one-and-only-onc 
instance of clnt InfoFrameGeneration. 


GetStatus 


Query the DAI for list of currently pending 
and/or completed InfoFrames™. 
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RetrieveFrame 


Retrieve a specific completed InfoFrame™ 
irom tne j->ai. 


RunAnaiystNow 


Send an InfoFrame™ Generation request to 
the DAI for immediate processing. 


ScheduleAnalyst 


Send an InfoFrame™ Generation request to 
the DAI with a schedule on which to run it. 


UpdateAnalyst 


Send the DAI a modification to an existing, 
scheduled Analyst. 


CancelAnalyst 


Cancel a previously scheduled InfoFrame™ 
Generation request. 



The InfoFrames™ API 1532 also uses the Communications Services module 
to communicate with the CSM 1404. 

The InfoFrame™ Generation API 1532 functions listed above are public 
members of the clnt_InfoFrameGeneration class. The clntJnfoFrameGeneration class will 
be instantiated only once, using the -Singleton" pattern (described previously). 

The Data Warehouse API 1533 provides services related to setting up 
Metadata™ 25, at which time the MDTA (Administrator) needs access to information 
about the schema of the Data Warehouse 24. This API 1533 cis encapsulated in the 
clnt_Schema class. The Data Warehouse API 1533 provides the following services to 
other MDT Client subsystems: 



Service Provided 


Description 


GetTables 


Returns a list of names of Tables from the 
current Schema data. 


GetColumns 


Returns a list of names of Columns from a given 
Table. 


GetPrimaryKeys 


Returns a list of names of Primary Keys in a 
given Table. 


GetForeignKeys 


Returns a list of Foreign Keys in a given Table. 


ForeignToPrimary 


Returns a list of Primary Keys associated with a 
given Foreign Key in a given Table- 


PrimaryToForeign 


Returns a list of Foreign Keys associated with a 
given Primary Key in a given Table. 
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Load Schema 


Loads schema from server; returns True if 




successful. 



The Data Warehouse API 1533 also uses the Communications Services 
module to communicate with the CSM 1404. 

The Data Warehouse API 1533 is encapsulated in the clnt_Schema class. 
The clnt_Scherna class has public member functions which correspond directly to the API 
calls described in the table above. The LoadSchema function loads all of the Data 
Warehouse schema onto the Client for the other API functions to access. The schema is 
discarded after each use. 

The Session Management API 1534 contains functions related to establishing 
a session with the MDT Server (and to closing the connection when exiting). This includes 
functions related to User and Password management. The Session Management API 
provides the following services to other MDT Client subsystems: 



Service Provided 


Description 


GetSessionManager 


Returns pointer to the one-and-only-one instance of 
class clnt SessionManagcr. 


Connect 


Establish a connection to the Server and attempt to 
authenticate the given User Name and Password. 


Disconnect 


Orderly shutdown of our connection to the Server 


UpdateUserPassword 


Change a User's password on the Server. 



The Session Management API 1534 also uses the Communications Services 
module to communicate with the CSM 1404. 

The Session Management functions listed above are public member 
functions of class clnt^SessionManager. Class clnt_SessionManager is instantiated once 
and only once, using the "Singleton" pattern. 

The Communication service encapsulates functions for talking to the DAI 14 
via the CSM 1404. These functions are shared by the four APIs 1531, 1532, 1533 and 
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1534 within the Server APIs subsystem 1403. The Communications Services capabilities 
arc encapsulated in class clnt_Communications, which will be a private superclass for all 
other classes in the Server APIs subsystem 1403. 

3. Data Abstraction Intelligence (DAD Subsystem 14 

The data abstraction intelligence subsystem 14 is described in further detail 

below. 

A key feature of the present invention (also referred to as Management 
Discovery Tool™ or MDT) is that it allows the user 1405 to easily choose different levels 
of granularity in the viewing and understanding of the objects of interest, and have these 
different levels reflected in InfoFrames™ generated by the MDT. For example, when the 
user 1405 thinks of the concept of product, he or she may mean all products marketed by 
the Enterprise, or, more likely, some interesting subset of all products. This subset can be 
defined by restrictions on the attributes of product, either a singte restriction such as men's 
clothing (defined as the product Department = men's clothing), or multiple restrictions, 
such as expensive men's suits made by Designer Y (similarly defined by restrictions on 
Department, Price, and Manufacturer). 

One of the insights in the design of the present invention is the notion that 
such subsets form hierarchies, and that these hierarchies may provide a convenient and 
powerful way for the user to both think about their and select relevant levels or 
granularities for the production of InfoFrames™. An important technical point, but one 
that is kept partially hidden from the user 1405, is how related segments form partitions. 

The Management Discovery Tool™ of the present invention sits on top of a 
data warehouse 24, a single logical, consistent view of an enterprise's data. Typically, 
there are many different ways to store data; that is, there are different table structures or 
schema for a given set of data. For most, if not all, enterprises, there exists a small set of 
fundamental data types that are the lowest level of granularity and correspond to, typically, 
specific entities like product, customer, transaction, and the like. These entities can be 
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thought of as having a set of attributes associated with them, and these attributes can have 
values. In the relational model, this corresponds to a table of entities, with the attributes 
mapping into columns. Again, physically, they may be stored as several tables, but 
conceptually, this is what MDT is working with. 

Fig. 16 illustrates the hierarchy formed by the user 1405 choosing the 
Department attribute 1601, then selecting segment Men's Clothing Department 1602 of the 
attribute; of choosing the Product-type attribute 1603, then selecting the segment Shirts 
1604 of that attribute; the Manufacturer Attribute 1605, then Designer X 1606; and finally, 
the Size attribute 1607, and a particular partition 1608/1609. The final Segment of interest 
is: "Designer X Men's Shirts". Note that this segment could have been reached in several 
different ways, in particular, by any order of relevant attributes. 

This scheme creates several requirements for other parts of MDT. First, the 
attributes of each dimension must be available. Second, the legitimate values for each 
attribute must also be made available. For finite domains, these must be listed for the user 
1405; for infinite domains, current minimum and maximum values may be useful. There is 
a subtly here that can perhaps be avoided at first: the possible attribute values may not, in 
fact, be appropriate in all cases. In the above example, all Manufacturers may not make 
Men's Shirts. It may be possible to query the database for legitimate values, or store this 
information as additional Metadata™. 

An important requirement of the present invention is to provide the ability to 
save and re-use user-defined segments. If "Designer X Men's Shirts" is an important 
category to the user 1405, he or she should be able to save that category and re-use it in 
the generation of InfoFrames™. Our approach allows users to define segments and 
automatically keeps these segments in a hierarchy. The table below provides a set of 
named segments and their definition, i.e. the restrictions on their attributes. All segments 
are on the dimension "Product**. 
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Name 


Dept. 


Maker | Type 


Size 


Men's Clothing 


MC 








Men's Shirts 


MC 




ohirts 




Designer X Shirts 




Designer X 


Shirts 




Designer X Men's 
Shirts 


MC 


Designer X 


Shirts 




Men's Pants 


MC 




Pants 




Large Men's Shirts 


MC 




Shirts 


Large 


Large Men's Pants 


MC 




Pants 


Large 


Gap Products 




Gap 






Designer X Products 




Designer X 






Guess Products 




Guess 






Medium and Large 
Men's Clothing 


MC 






Medium + 
large 


Small Men's Clothing 


MC 






Small 


Small Men's Shirts 


MC 


Shirts 




Small 



The segments described above give rise to the segment hierarchy depicted in 
Fig. 17. Note that there is an inherent ambiguity in this structure: a given Segment can 
belong to several different partitions and have children beneath it whom are in several 
different partitions. For example, the Segment "Designer X-men's-shirts" belongs to two 
partitions. The first partition is on "Designer X-shirts" and uses the value "men's" to 
further discriminate (note the "Other" segment would now mean "Designer X-shirts-but- 
not-for-men". This segment is also part of a partion on "mcn's-shirts", and restricts the 
Manufacturer attribute to be Designer X. Here p the "Other" segment indicates "men's- 
shirts-made-by-everybody-but-Designer X". 

In order to resolve the ambiguity, the notion of partition must be made 
explicit. Thus, Fig. 17 may be re-drawn as shown in Fig. 18 to include partitions (dark 
boundaries) and the "Other" segments. We now see from Fig. 18 that the notion of 
"partition" is just as important as the notion of "segment"; indeed, the two notions cannot 
be separated. 
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Referring back to Fig. 1, the MDT Data Abstraction Intelligence (DAI) 
subsystem 14 sits between the Client subsystem 12 and the Data and Schema Manipulation 
(DSM) subsystem 16. The DAI 14 (and the DSM 16) reside on the Applications Server 32 
between the Desktop 30 and the Data Warehouse 24. The DAI 14 is responsible for 
instantiating user selected InfoFrames™ and managing several kinds of Metadata™ used in 
this instantiation. This Metadata™ represents (1) Dimensions and Measures that provide a 
customizable "dimensionalization" of the relational data in the warehouse; (2) Measure 
Relationships that provide explanatory text in the InfoFrame™; and (3) Metadata™ related 
to time. The DAI 14 also processes updates to this Metadata™ that originate in the Client 
layer 12 and handles several other kinds of user updates, primarily by passing them 
through to the DSM 16 subsystem. Finally, the DAI 14 executes Alert requests from either 
the Client 12 or the Scheduler subsystem 18. 

The design of the overall Client/Server envisions two kinds of DAI 
subsystems 14. The first kind of DAI 14 is needed to handle continual, synchronous 
requests for information from the Client 12. For example, the Client 12 may make a 
number of requests for information during an active MDT session; the S-DAI (for Serial 
DAI) will handle these requests. 

The second kind of DAI 14 will execute an Analyst, which may contain a 
trigger definition or an InfoFrame™ definition. This execution may take a relatively long 
time (e.g., hours) and will execute concurrently. This type of DAI 14 may be called the C- 
DAI , for Concurrent DAI. The C-DAI is spawned by an S-DAI in response to an 
InfoFrame™ request and given all the information it needs. When it is finished, it will 
write the resulting InfoFrame™ into a server disk file. 

Fig. 19 shows the general, high-level data flow between the DAI 14 and the 
other subsystems and components of the present MDT invention. 

When a user logs onto the present invention, a Serial DAI (S-DAI) 14A is 
created to service various kinds of requests. All user requests from the Client 12 flow 
through the Client/Server module (CSM) 1404, which controls communication between 
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Client 12 and Server 32. Requests for Metadata™, both read and update, (write) requests, 
are handled by the S-DAI. Read requests cause the S-DAI to query the Data and Schema 
Manipulation (DSM) module 16 for Metadata™ contained in the MDT Metadata™ tables. 
The S-DAI handles update requests by using the "Classic subsystem", a system for 
managing heirarchical data structures available from Bell Laboratories of Lucent 
Technologies. The Classic subsystem may be used to check and properly position new 
user segments in the segment hierarchy. The Serial DAI also handles requests for 
previously generated InfoFrames™, fetching them from the Server disk. 

When a user requests that an Analyst be generated, a Concurrent DAI 14B is 
created by the Dispatcher (if resources permit), and the Concurrent DAI 14B is passed all 
the information in the Analyst definition. The Concurrent DAI 14B then uses its built-in 
algorithms and Metadata™ requested from the CSM 1404 to generate the InfoFrame™ 
which is then stored on the Server disk. 

The CSM module 1404 provides the low level services that pass messages 
from one process to another. Certain classes may be built on top of the CSM 1404 that 
make it easier to use, as described in further detail below. 

The message-passing design consists of 5 classes and an enumerated type. 
mdt_MessageType, the enumerated type has a unique value for each type of message in 
MDT; mdt_TlnStreamHandle and mdtJTOutStreamHandle are handles for incoming and 
outgoing message streams respectively; mdt_Message is an abstract base class for all MDT 
messages; dai_MessageHandler is an abstract base class for objects that can handle 
messages; finally, dai_MessageRegistry is the registry of message handlers. 

mdt_MessageType is defined below, 
enum mdt_MessageType { 

UNDEFINED, 

CS_LOGIN, 

SCJLOGIN_RESPONSE, 
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CSJ3ENERATEJNFOFRAME, 
CS_GET JNFOFRAME_STATUS , 
SC_INFOFRAME_STATUS , 
CS_GETJNFOFRAME, 
SCJNFOFRAME, 
END_OF_ENTJM 

}; 

mdt_MessageType is an enum than defines all the message types understood 
by MDT processes. For each class derived from mdt_Message, there must be at least one 
value in mdt_MessageType. This declaration of mdt_MessageType is used by all 
components of MDT. The message types shown are only a sample. The message types 
currently defined below are only a sample. This definition will evolve as MDT code is 
written. 

mdt_TlnStreamHandle is defined below, 
class mdtjnnStreamHandle : public csrnJnStrearnKandle { 
public: 

mdtJTInStreamHandleO : d_mtype(UNDEFINED) {} 
virtual void Connect(RWvistream *); 
rndt_MessageType GetMessageTypeO const; 
private: 

mdtMessageType d_mtype; 

}; 

mdtjnnStreamHandle is a typed handle for incoming (received) message 
streams. An mdtjnnStreamHandle is used to pick up an incoming message stream from 
the CSM module 1404. The mdt_TInStream Handle automatically reads the message's type 
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from the incoming message stream and provides a member function to get that message 
type. Users of mdt_MessageRegistry need not use this class. 

md t_TOu tS IreamHand le is defined below, 
class mdtJTOutStrearnHandle : public csrn_OutStreamHandle { 
public: 

mdtJTOutStreamHandle(mdt_MessageType t) : d_mtype(t) {} 
virtual void Connect(RWvostream *); 
mdt_MessageType GetMessageTypeO const; 
private: 

mdt_TOutStreamHandleO; 
mdt_MessageType d_mtype; 

}; 

mdtJTOutStrearnHandle is a typed handle for outgoing message streams. An 
mdtJTOutStrearnHandle is used to send a streamed message out via the CSM 1404. The 
mdt TOutStreamHandle has a message type and automatically writes it's message type to 
the stream so that the mdt_TInStreamHandle on the receiving end can decode the message 
type. 

mdt_Message is defined below, 
class mdt_Message { 
public: 

mdt_Message() : d_restoreVersion(0), d_restoreFlag(false) {} 

mdt_Message(const mdtMessage &); 

virtual mdt_MessageType GetMessageTypeQ const; 

virtual int GetLatestVersionO const = 0; 

virtual void SetResto reversion (int restore Version); 



79 



(207) 



10-2077 



virtual int GetRestoreVersionO const; 

virtual void saveGuts(RWvostream &) const; 

virtual void restoreGuts(RWvistream &); 

virtual bool IsRestoredO const; 
protected: 

virtual void SetRestoredF!ag(bool); 
private: 

booJ d_restoreFlag; 

int d_restoreVersion; 



Requests and Replys are communicated between Client 12, Serial DAI 14 A, 
Concurrent DAI 14B, Scheduler 18 and Dispatch 2513 by the Client/Server Module (CSM) 
1404. 

CSM 1404 implements an mdt_Message class which will be used for 
sending or receiving Requests or Replies. A receiving indtjvfessage will contain an input 
stream. A sending mdt_Message will contain an output stream. A stream is a well known 
C+ + construct which allows the user to Stream' the elements of a long message into a 
buffer, or to stream the elements of the message out of a buffer. 

Each of the Request and Replies implemented for the present MDT 
invention are represented by a message derived frmo the mdt_Message base class and has 
appropriate functions for streaming itself into or out of a stream. 

The CSM 1404 implements a csm_SimpleSocket and a csm_ServerSocket 
class. Each type of socket contains a TCP/IP socket. A TCP/IP socket is a well known 
API to a TCP/IP network. Other implementations are envisioned. Each type of socket can 
extract the stream buffer from a message and send it via the socket to a recieving 
csm_Simple or csm_ServerSocket ) or can receive a stream buffer from a sending 
csm_SimpleSocket and install it in a message. 
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A csm_SimpleSocket is used to communicate messages between MDT 
subsystems in a committed, one to one relationship. A csm_ServerSocket is used to allow 
an MDT subsystem to accept messages from many other subsystems. 

In Fig 25, the Client subsystem 12 will maintain a csm_SimpIeSocket which 
it will use to request a SD AI subsystem 2512 from the Master subsystem 2511, and which 
it will use thereafter to exchange messages with that SDAI subsystem. The Client 12 will 
use this socket whenever a user input to the Client 12 requires an exchange with the 
Server. 

In Fig 25, the Master subsystem 251 1 will maintain a csm_ServerSocket to 
receive messages from any Client subsystem 12 which wants to request an SDAI subsystem 
14A. Excepting when the Master is activly starting or otherwise tending to the SDAI's, it 
will be listening at the csm_ServerSocket. 

The SD Al subsystem 2511 will maintain a csm^SimpleSocket to exchange 
messages with the Client subsystem 12. Except when it is actually implementing a Client 
request, the SDAI 14A will be listening at its csmSimpleSocket. 

When the user 1405 submits an Analyst for immeadiate execution, the SDAI 
subsystem 14A will construct a new csm_SirnpleSocket to communicate the Analyst to the 
Dispatcher 2501. When the user sumbits a Scheduled or Triggered Analyst, the SDAI will 
construct a csmSimpIeSocket to communicate the Analyst to the Scheduler 18. 
The Scheduler 18 will maintain a csm_ServerSocket to collect Scheduled or Triggered 
Analysts from any and all SDAI subsystems 251 1. When the Scheduler determines the the 
time has come to launch a Scheduled or Triggered Analyst, it will construct a 
csm_SimpleSocket to communicate that Analyst to Dispatcher subsystem 2513. Except 
when it is testing its Scheduled and Triggered Analyst lists or dispatching them, the 
Scheduler will be listening at its csm_SimpleSocket. 

The Dispatcher subsystem 2513 will maintain a csmServerSocket to collect 
Analysts for execution from any ready SDAI subsystem 251 1 or from the Scheduler 
subsystem 18; or to collect Analyst requests from the CDAI subsystem 14B. When an 
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SDAI or the Scheduler presents an Analyst, the Dispatch will hold it until resource become 
available for its execution. When resources are available the SDAI will start a CDAI 14B. 
When the CDAI returns a request for the Analysts, the SDAI will create a 
csm_SimpleSocket to communicate that Analyst to the CDAI. Except when it is starting 
managing CDAIs, the SDAI subsytem 2513 will be listening at its csm_ServcrSocket. 

The CDAI subsystem 14B will construct a csm_SimpleSocket shortly after it 
is started to collect its Analyst from the Dispatcher subsystem 2513. After collecting this 
message, it will discard the csm_SimpleSockct. The CDAI 14B will exchange no other 
messages with the other subsystems of the present invention. 

The mdt_Message abstract base class defines the object that holds the 
content of an MDT interprocess message. Each message has a message type, a message 
version, and the ability to read/write its data from/to a stream of message data. For each 
type of message, there is a concrete implementation of a class derived from mdt_Message. 
Each message class must implement GetLatestVersion to return its version and 
GetMessageType to return its mdtJvlessageType. It must also implement the Rogue Wave 
saveGuts and restoreGuts methods to write its persistent member data to a stream and read 
the member data back from stream. Unpacking order is first in first out. There is only one 
derived message class per message type, but there can be several message types used by a 
derived message class. The same message code should be linked into both the sending and 
receiving processes. Version checking is used to robustly handle mismatches between the 
version of the code in the sending process and the receiving process. The message version 
is used by restoreGuts to insure that an incoming message stream can be restored and to 
migrate streams saved by older versions of the class to the current version. An 
mdt_Messages is sentyreceived from the CSM module 1404 by saving/restoring its guts 
to/from the stream pointed to by the mdtJTOutStream Hand le/mdt_TInStream Handle class 
defined above. 



dai_MessageHandler is defined below. 
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class dai_MessageHandler { 
public: 

virtual bool HandleMessage(const mdt_Message &) = 0; 

}; 



dai_MessageHajidler is an abstract base class for message handler classes. 
If the process uses the message registry to dispatch received messages, at least one 
concrete message handler class must be implemented. As many as one message handler 
per registered message may be implemented.. 



dai _MessageRegistry is defined below, 
class dai_MessageRegistry { 
public: 

dai_MessageRegistry( csrn_ Connect &); 

void DispatchMessagesO; 

void RegisterMessage(mdt_MessageType, 
dai_MessageCreateFunc, 
dai_MessageHandler &); 

private: 

dai_MessageCreateFunc d_createFunc; 
dai_MessageHandler *d_handler; 
csm_Connect *d_connect; 



dai_MessageRegistry is a class meant to be instantiated only once in each 
process that uses it. The message registry provides a method to register a handler for each 
message type and a method to dispatch all incoming methods. The dispatch method acts as 
the application's main loop. The return value of the HandleMessage method of the handler 
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determines whether DispatchMessages blocks or returns after a message is processed. If 
the return value is true, it blocks. 

The following is the set of events that occur as a message is transmitted 
from one process to another using the MDT typed stream handles and the message registry. 

1 . sending process constructs an instance of a concrete message class (derived 
from mdt_Message), MS and loads it with the proper message data. 

2. sending process creates an mdtJTOutStreamHandle object with the same 
message type as the message. The mdtJTOutStreamHandle object writes the 
message type to the stream. 

3. sending process uses the message's saveGuts member function to write the 
message to the message stream. 

4. message's saveGuts method first calls base class method which writes the 
message's version number to the stream. Next it saves the message's 
persistent member data fields to the stream. 

5. sending process calls csm SendProceyjConnectciSendO to send the message 
stream. 

6. The CSM extracts bytes from the stream object and sends the bytes to the 
receiving process. 

7. When the mdtJTOutStreamHandle object is destroyed, it in turn destroys the 
stream object it was connected to. 

8. The receiving process should be waiting in a call to 
csm_ReceiveProc^::ReceiveO. Internally, there is probably some queuing 
of messages. 

9. The CSM in the receiving process gets the oldest queued message. It then 
converts the bytes into a stream object and connects that stream to the 
mdt_TlnStreamHandle object that was passed to 
csm_ReceivePr0cey.r: :Receive(). 



84 



(212) 



10-207751 



10. When the stream is connected to the handle, the handle reads the message 
type from the stream and remembers it. 

11. Finally, control returns from csmJReceivcP/t?cdJj::Reccive() to the caller. 

12. The receiving process gets the message type from the mdt_TInStreamHandle 
and constructs an empty instance of the right type of message class for that 
message type. If the message dispatcher is in use, this is handled by 
dai_MessageRegistry : : DispatchMessagesO . 

13. The receiving process calls the message's restoreGuts function. If the 
message dispatcher is in use, this is handled by 
dai_MessageRegistry::DispatchMessages(). 

14. The message's restoreGuts method first calls the restoreGuts method of its 
base class (usually mdt_Message) which reads the version number and saves 
it as the Restore Version member. Next control returns to the derived version 
of restoreGuts. It calls GetRestore Vers ion and uses the resulting version 
number to determine which data members to read from the stream and what 
order to read them in. Next the data fields of the message class are read 
back from the stream. 

15. The received message is now in its final form. If the dispatcher is in use, it 
looks up the handler for this message type in the registry and calls its 
HandleMessage method. 

16. When the mdt_TInStream Handle object used to receive the message is 
destroyed (or reconnected by another call to 

csm_Receive/Y0ce.y.r::ReceiveO, the stream it was pointing to is deleted. 

The present MDT invention enables or other users to monitor their data 
warehouse 24 by defining powerful report-generation objects called Analysts. An Analyst 
is an encapsulation of a generic type of analysis, customized by the user 1405 by providing 
a set of parameters, a schedule, and a trigger condition. The Analyst periodically checks 
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the trigger condition if it has a trigger condition, or periodicaJly executes on the schedule if 
it has a schedule. Otherwise it executes right away. InfoFrames™ contain a variety of kinds 
of data and hyperlinks which can be used to run other Analysts and generate related 
InfoFrames™. The functionality of MDT. including Analyst definition and InfoFrame™ 
generation, requires an "MDT view" of the data warehouse 24 that we refer to as "MDT 
Metadata™" 25. 

The word "Metadata™", in general refers to various kinds, of "data about 
data" in a database or data warehouse 24 (Fig. 1). MDT Metadata™ 25 provides a 
customizable view of the data not restricted by the relational structure of the database. 
MDT Metadata™ 25 is stored in the data warehouse 24 as a set of tables and is read by 
MDT present invention during start-up. Populating the Metadata™25 in the warehouse 24 
is a key part of the MDT installation process, and an MDT Administrator will generally 
be needed to extend and maintain the MDT Metadata™ using knowledge of the structure of 
the data warehouse 24. 

There are 4 main kinds of MDT Metadata™: (1) Dimensions and Attributes, 
(2) Segments and Partitions, (3) Measures, and (4) Measure Relationships. The present 
specification describes each kind of Metadata™ with a series of tables. Each table shows the 
column names and the types of the data values in that column (in parentheses). Some 
columns define MDT-oriented entities or objects, and others provide mapping information 
between MDT Metadata™ and the relational schema of the warehouse. Primary keys for 
each table are italicized (if more than one column name is italicized, the combination of 
those column names forms the key). 

MDT Metadata™ 25 includes an explicit notion that certain data attributes 
can have a finite set of values. These are referred to as "enumerated attributes". For 
example, the present invention can represent the fact that the values for the attribute 
"State" are limited to a finite set of values (that is, each of the 50 States of the United 
States, in whatever encoding the data warehouse uses). The MDT Metadata™ tables also 
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refer to, for convenience, sets of values that are represented in enumerated types in source 
code header files. The word "enurrT refers to column values of this type. 

The table representation of MDT Metadata™25 is first described in 4 
sections, one for each main kind of Metadata™. The following are then described: 
representation of time in MDT, the kinds of Metadata™ that need to be stored in source 
code header files, and the issue of populating the Metadata™ tables during installation is 
discussed. 

Dimensions are the suiting vocabulary for the domain: they define the high- 
level categories of entities. For example, in a retail domain, the Dimensions might be: 
Product, Market, and Time {Time is a universal Dimensions applicable to most domains 
and is discussed in a later section). Each Dimension has a set of attributes that can be used 
to describe its entities; for example, the various attributes for Product, like Department, 
Price, Style, and Manufacturer. 

AH tables in this section are set up during installation and are unlikely to 
change often, because they are all heavily dependent on the structure of the data warehouse 
24 and the industry-specific view of the data. None of the tables in this section are 
generally modifiable by the end user, although occasional modification may be needed by 
the MDT Administrator to extend MDT Metadata™or respond. to changes in the relational 
schema of the data warehouse. 

As shown in the following table, dimensions are represented by their name 
and an associated Id. The Id is used to join with other tables more efficiently. The Seg-Id 
is the Id of the top-level segment for this dimension, and the Comment is a comment. 



7256jDirn 
-Id 
dm) 


Name 
(string) 


Seg-Id 
(int) 


Comment 
(string) 


001 


Product 






002 


Market 















87 



(2 15) 



»H¥ 10-207 



The following table represents all of the attributes for each Dimension. Each 
attribute has a unique Id (Attr-Id), a name, and the Id (Dim-Id) of the Dimension they 
belong to. Attributes for different Dimensions can have the same name (but they will have 
different Ids). MDT-Type indicates the MDT type of the attribute. Each attribute is 
mapped to a single table and column, and we encode the data type of the field in the 
database that each attribute maps to (Column-Type). All the attributes for a given 
Dimension can be extracted from this table using the Dim-Id field. The enurn values for 
MDT-Type are: enum, int, float, restricted-int, restricted- float, string. The enurn values 
for Column-Type are all those types supported by the data warehouse. 



Atlr-Id 


Name 


Dim-Id 


MDT- 


Table 


Column 


Column- 


Comment 


(int) 


(string) 


(int) 


Type 
(enum) 


(string) 


(string) 


Type 
(enum) 


(string) 


006 


Manufacturer 


001 


enum 










016 


Size 


001 


int 










0057 


Region 


002 


enum 










017 


Department 


001 


enum 










0099 


Size 


002 


float 



























Y/ith respect to attributes that are enumerated types, the following table 
represents the legitimate values for these attributes. These values will have both a user 
name, like "Men's Clothing" and the name of the actual data value, like u Dept-017 n . The 
information in these tables can be partially generated by a "Select ... Distinct ..." query 
for the attribute. 
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Aitr-Id 


Display-Name 


Data-Name 


(int) 


(string) 


(string) 


0017 


Men's Clothing 


Dept-017 


0017 


Housewares 




0017 


Hardware 




0057 


Southern 











For attributes that have type integer, the following table defines the t 
appropriate ranges of values and a "typical value" if this would be useful to present to the 
user. Not all integer attributes have to appear in this table, if they do not have natural 
ranges and typical values. 



Attr-Jd 
(int) 


Min 
(int) 


Max 
(int) 




0 


120 









For attributes that have type float, the following table defines the 
appropriate ranges of values and a "typical value 7 * if this would be useful to present to the 
user. Not all float attributes have to appear in this table, if they do not have natural ranges 
and typical values. 



Attr-ld 
(int) 


Min 
(float) 


Max 
(float) 


"income 


0 


1000.00 









A key part of the MDT Metadata™ 25 are a set of segments and partitions 
for each Dimension. A segment is a set of attribute restrictions that define a class of objects 
of interest. For example, "Stores remodeled less than one year ago", or "non-seasonal 
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store-wide promotions", or "Designer X shirts of size 14 and larger". Segments are 
arranged in hierarchies, one for each Dimension. The hierarchies are further organized 
using the concept of a partition: a set of related segments differing only by the restriction 
on a single attribute. Segments and partitions are represented by a set of tables that capture 
the segrnenL/partition hierarchy for each Dimension and define the attribute restrictions for 
each table. 

The following table names each segment and the Dimensions it is a part of. 
and provides the name and the owner of the segment. The Owner string for segments that 
are globally owned will be defined in a header file; here and elsewhere it is shown as 
"ALL*. There is a so-called "top-level segment* 1 for each Dimension with the name "All 
X", where X 
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is the Dimension name. The Num-Attrs field contains the number of attributes used to 
restrict this segment. For the "top-level segments", Num-Attrs will be equal to 0. 



Seg-ld 


Dim-Id 


Name 


Owner 


Num-Attrs 


Comment 


(int) 


(int) 


(string) 


(string) 


(int) 


(string) 


112 


001 


Men's Clothing 


ALL 






26 


001 


Men's Shirts 


ALL 






14 


001 


Designer X Shirts 


PES 






117 


001 


Designer X Men's Shirts 


pgs 



















The following table represents all the numeric attribute restrictions for each 
segment represented in the following interval notation. In the first row above, if Attr-Id 
017 stands for the Attribute "Size", then this row would read; M 0 < = Size < = 100"; 
that is, "Size is greater than 0 and less than iCXT. Values are represented as Strings so 
restrictions of attributes of other type {like float or currency) can also be represented. The 
enum values of Operator- 1 are: greater than, less than, greater than or is, less than or is, 
is, is not, is between. 



Seg-ld 
(int) 


Attr-Id 
(int) 


Value-1 
(float) 


Opcrator-1 
(enum) 


Yaluc-2 
(float) 


112 


017 


0 


"between" 


100 


112 


018 








14 










117 





















The following table represents all the set or enumerated type attribute 
restrictions for each segment. The The "Data Name" column is the same as before. For 
example, one might represent the segment "East Coast Cities" and define it as the set 
{New York, Boston, Washington, ...}. To do this, several entries, one for each city, 
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would appear in this table. This table can also be used to represent string attribute 
restrictions. The enum values for Operator are: is, is not, is in list, not in list. 



Seg-Id 
(int) 


Attr-Id 
(int) 


Operator 
(cnum) 


Data Name 
(string) 


112 


019 


"in list" 


Seattle 


1J2 








14 








117 

















The following table defines each partition and the attribute it is defined over. 
The default partition name is that same as that of the attribute it is defined over. In this 
case, the user interface will display the partition name by appending u by- w as a prefix. The 
Name can be updated by the user 1405. 



Prtn-Id 
(int) 


Name 
(string) 


Owner 
(string) 


Attr-Id 
(int) 


59 




ALL 


0059 


1 17 




PES 


0017 











The following table and the next define the segment/partition hierarchy. This table 
represents the child partitions of each segment. This table can also be used to find the 
parent segments for a given partition. 



Seg-Id 
(int) 


Prtn-Id 
(int) 


112 


59 


13 


117 







92 



(220) 



^H^P 10-207751 



The following table represents child segments for each partition. This table 
can also be used to find the parent partitions for each segment. 



Prtn-Id 
(int) 


Seg-Jd 
(int) 


19 


15 


221 


222 







Measures are values in the data warehouse 24 that can be measured over the 
data. For example, Sales, Price, and Market Share are all measures in the retail domain. 
Different Measures are "rolled up w differently; for example, Sales over several markets are 
added while Market Share is averaged. The present MDT invention provides a set of Basic 
Measures during installation and allows the user to combine them to form more 
complicated Composite Measures using formulas. 

The following table names the Measure, defines its rollup mechanism, and 
maps the Measure to a table and column. The Display Units column is for InfoFrame™ 
generation only. Precision is the number of digits needed to the right of the decimal point. 
The enum values for Rollup are: add, average, count. 



BM-ld 
(int) 


Name 
(string) 


Rollup 
(enum) 


Table 
(string) 


Column 
(string) 


Display 
units 
(string) 


Precision 
(int) 


Comment 
(string) 


055 


Sales 


add 












0917 


Discount 
factor 


average 





























Composite measures are built by combing basic measures, certain binary and 
unary operations, and special keywords that indicate, for example, the target segment, the 
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child segments of a partition, or the sibling segments of a target segment. In addition, one 
can encode a set of segments to restrict a measure, using the next table. The Left-Arg and 
Right-Arg encode the kind of argument in "Left-M" or "Right-M", as shown here: 

1. Basic measure 

2. Composite measure 

3. "Target segment" 

4. "Parent segment'* 

5. Segment list: 2d argument is the Slist index (see next table). 

6. Sibling segments 

7. Child segments 



If the operator in Op is a unary operator (count, sum, average), then only 
the Left-M is used. If the operator in Op is a binary operator ( + , etc.), then both the 
Left-M and Righl-M are used. 



CM- 
ld 
Pnt) 


Owner 
(string) 


Name 
(string) 


Display 
Units 
(string) 


Left-M 
(int) 


Left-Arg 

type 
(enum) 


Op 
(enum) 


Right-M 
(int) 


Right- 
Arg type 
(enum) 

























































If the Composite Measure references a list of segments, then the elements of 
the list are represented in the following table. 



CM-ld 
(int) 


Seg-Id 
(int) 


17 


5 


17 


6 



94 



(2 22) 



MfBPPl 0-207751 



The following table is used to join an attribute with a basic measure to 
evaluate a dimensional query. The idea is that, for each attribute (that maps to a table and a 
column) and for each measure (that also maps to a table and a column), you need to be 
able to join their two tables. This table gives the column names for. the two equivalent 
columns (keys) that can be used in the join. 



Attr-Id 
(int) 


BM-Id 
(int) 


Attr- 
Column 
(string) 


BM- 
Column 
(string) 


5 


8 


u cust_age" 


"mkt_share 











The following table is used to join two attributes together to evaluate a 
dimensional query. That is, if the previous table (above) is not sufficient to join all 
attributes in a dimensional query to the measure, this table can be searched to try to find a 
path of attributes that can be used to create multiple joins to combine all attribute tables 
with all measure tables. 



Attrl-Jd 
(int) 


Attr2-Id 
(int) 


Attrl- 
Column 
(string) 


Attr2- 
Column 
(string) 


17 


4 


"cust age" 


age 











A Measure Relationship is a qualitative description of causality between 
Measures. For example, in general, if "Shelf Space" for a product goes up, then one 
would expect "Sales" to go up as well. In this example, "Shelf Space" is the independent 
Measure and "Sales" is the dependent measure. However, Measure Relationships are more 
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complicated than a simple statement of causality and direction. One would not expect the 
above example to hold over all values of "Shelf Space" but only some range of values. 
Similarly, one might expect the relationship to hold only if the "Shelf Space" increased by 
some reasonable percent. Also, one might expect a measure relationship to hold only fur 
some segments but not for others. 

The following table defines basic Measure Relationships as follows. The 
value for the column I-Direction is either "direct" or "inverse", an enumerated type 
defined in a header file. If the value is "direct' 1 , then if the Independent Measure goes up, 
the Dependent Measure should go up. If the value is "inverse* , then if the Independent 
Measure goes up, the Dependent Measure should go down. The enum values for I- 
Direction axe; direct, inverse. 



MR- Id 

(int) 


Owner 
(string) 


Indepcdent M-Id 
(int) 


I-Direction 
(enum) 


Dependent M-Id 
(int) 


019 


PCS 


5 


"direct" 


21 













The following table restricts the Measure Relationship to a certain range of 
values of the Independent Measure. The Operation can be > , < , > < = , = f not = , c 
between. For between, both Value-1 and Yalue-2 are used. The enum values for 
Operation are: is less than, is greater than, is less than or =, is greater than or =, is, is 
not, between, not between. 



MR-ld 
(int) 


Operation 
(enum) 


Value-1 
(float) 


VaIuc-2 
(float) 


019 


"between" 


5 


100 
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The following table applies only lo Measure Relationships with the Change 
Analysis Analyst definitions. It restricts the Measure Relationship to apply only when the 
Independent Measure changes appropriately over the time period of the Change Analysis. 
The enum values for Direction are: increases, decreases. 



MR-Id 
(int) 


Direction 
(enum) 


Value 
(float) 


Unit 
(string) 



















The following table restricts the applicability of Measure Relations by 
segment. Note that if a Measure Relation applies to a given segment, it will also apply to 
all children segments. 



MR-Id 
(int) 


Seg-Id 
(int) 


055 


19 







(a) 

Time is an important pan of MDT Metadata™ 25. At one level, we would 
like the user to think of Time as another Dimension; however, because Time segments can 
be created on-the-fly (for example, the segment "Year-to-Date"), they are represented 
differently. We show this representation as a set of tables, although some of the 
information may be defined in source code header files. 

The following table defines the lowest unit of granularity of time represented 
in the data warehouse 24. We are assuming that all representations of time in the data 
warehouse uses this single unit of time. The enum values for Base Unit are: day, week, 
month, year. 
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Base Unit 
(enum) 
Day 



If a database table is used by a measure, that table must have a column for 
time in it. The following table lists the columns for each table that represent time, for each 
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basic measure. 



Table 
(string) 


BM-Id 
(int) 


Column 
(string) 


Transaction 




Time- 
stamp 















The following table defines the different notions of year that may be 
important to the user 1405. The cnum values for Wee* Stan Day are: Sunday, Monday, 
Tuesday, Saturday. 



Name 
(string) 


Start Month 
(string) 


Start Day 
(int) 


Week 
Start Day 
(enum) 


Comment 
(string) 


Calendar 


January 








Fiscal 


May 






i 
i 



> Jan 
! Start 
! (int) 


Feb 
Start 
(int) 


Mar 
Start 
(int) 


Apr 
Start 
(int) 


May 
Start 
(int) 


Jun 
Start 
(int) 


July 
Start 
(int) 


Aug 
Start 
(int) 


Sept 
Start 
(int) 


Oct 
Start 
(int) 


Nov 
Start 
(int) 


Dec 1 
Start ! 
(int) .! 



















































Quarter 1 
Begin 
Month 
(int) 


Quarter 1 
Begin 
Day 
(int) 


Quarter 2 
Begin 
Month 
(int) 


Quarter 2 
Begin 
Day 
(int) 


Quarter 3 
Begin 
Month 
(int) 


Quarter 3 
Begin 
Day 
(int) 


Quarter 
4 

Begin 
Month 
(int) 


Quarter 4 
Begin 
Day 
(int) 
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The SeriaJ DAI (S-DAI) J4A (Fig. 19) is responsible for providing access to 
MDT Metadata™25 to each Client 12. When a Client 12 logs into MDT, a Serial DAI 
14A is created and connected to the Client session. All Client requests for Metadata™, 
including update requests, are handled by the Serial DAI 14A. In addition, the S-DAI 14A 
provides access to the MDT Administrator, allowing him or her to configure MDT using 
the setup screens. 

The architecture of the Serial DAI is shown in Fig. 20. 

The Serial DAI 14A gets requests in the form of MDT messages from the 
Client 12. Each MDT message has its own "reply class" in the S-DAI 14A. Messages for 
Metadata™ access and simple update are handled through the Metadata™ table interface of 
the DSM 16 (that is, without using the Classic component 14AA — defined further below). 
Requests to add or delete segments use the Classic component 14AA to validate the request 
and update the hierarchy as needed. 

Metadata™ access and simple update services are provided to the Client 12 
by the Serial DAI 14 A without use of the Classic component 14AA. Whenever the Client 
12 needs a particular piece of Metadata™, typically to present in the user interface, the 
Client 12 will send a request message to the S-DAI 14A. The S-DAI 14A will access the 
appropriate Metadata™ tables 25 to extract the appropriate Metadata™ . It will then package 
it up and return it to the Client 12 in one or more messages. The Metadata™ interface 
automatically provides access to public Metadata™ and the Metadata™ for this particular 
user. 

The general flow of data and control is shown in Fig. 21 and described 

below. 

• [step 2101] The Client 12 sends a Metadata™ request message to the S-DAI 
14AA. This message includes the the message type and the required 
parameters. . 

• [step 2102] The Serial DAI 14A examines the message type and determines 
which Metadata™ table 25 is needed. 
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• [step 2103] Using ihe parameters, the S-DAI scans the Metadata™ tab lc(s) 
25 for the correct Metadata™. 

• [step 2104] The Serial DAI 14A packages the Metadata™up. 

• [step 2105] The Serial DAI 14A sends a Metadata™ message back to the 
Client 12. 

In the unlikely event of an error, the S-DAI 14A will log the error in the 
server error log and return an error code to the Client 12. There may be several kinds of 
errors of varying severity. 

New Composite Measures are added from the Client 12 using the user 
interface. Any syntactic or semantic checking will take place there. The syntax for 
Composite Measures is shown above. When the Client 12 indicates that a new Composite 
measure has been created, the Serial DAI will add the information to the appropriate 
Metadata™ table, discussed previously. 

An existing Composite Measure can be updated by pulling up an existing 
measure in the Measure Builder screen, editing it, and hitting the Save button. The edited 
Composite Measure will be saved to the Metadata™ tables 25 using the same Composite 
Measure Id. The Client 12 will display a warning message to the user 1405 to the effect 
that, if this Measure is being used in an Analyst, the meaning of the results presented in the 
subsequent InfoFrame™ will be different. 

A Composite Measure can be deleted if it is owned by the user. The 
Composite Measure and its formula entries will be deleted from the appropriate table, 
previously described. A warning message will be presented to the user 1405, warning that 
if this Compound Measure is used by any Analyst or other Compound Measure, the 
subsequent JnfoFramc™ will not be generated correctly and an "analyst-time" error will 
occur. 

Adding a new measure relationship is similar 1 to adding a new Composite 
measure. All checking, if any, will taJce place in the Client 12. When the Client indicates 
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that a new measure relationship has been created, the Serial DAI 14 A will add the 
information to the appropriate Metadata™ tables. 

Modifying a measure relationship is straightforward. The appropriate tables 
are updated and the measure relationship id is preserved. A Measure Relationship can be 
deleted if it is owned by the user 1405. The Measure Relationship and its table entries will 
be deleted from the appropriate tables. A warning message will be presented to the user, 
warning that if this Measure Relationship is used by an Analyst, the subsequent 
InfoFrame™ will not be complete and an "analyst-time" error will occur. 

The Serial DAI 14A also processes requests from the MDT administrator. 
These requests are used to install MDT and maJce occasional changes to the public 
Metadata™. The Serial DAI I4A must handle the flow of information from both the data 
warehouse 24 to the Client 12 (sending both data warehouse schema information and 
Metadata™) and from the Client 12 to the data warehouse 24, in this case exclusively to the 
Metadata™. The Serial DAI 14 A is not expected to have to do any processing on the data 
itself, i.e., to do additional integrity or exception checking. 

The data warehouse schema is passed to the Client 12 in one uninterpreted 
bundle and the Client 12 will interpret it. There are eight steps to setting up or installing 
MDT. Each step involves the Client 12 getting information from the Administrator through 
the user interface and passing information to the S-DAI 14A. The S-DAI I4A will update 
the Metadata™ tables through the DSM interface. These steps are: 

1. define dimensions 

2. define and map attributes to database columns 

3. rename coded attribute values 

4. create basic segments 

5. define and map basic measures to database columns 

6. review the joins between database tables 

7. assign database columns as time markers 

8. define year types 
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Classic 14 A A is used to represent the user's segment and partition 
hierarchy, as described previously. When a user adds, modifies, or deletes a segment, the 
Classic component 14AA determines any and all changes that need to be made to the 
segment/partition hierarchy, or detects one of several possible kinds of errors. If there are 
no errors, these changes are then used to update the Client interface and the persistent 
Metadata™ tables. This is shown in Fig. 22: 

• [step 2201] The Client 12 sends a segment update request, either an add, 
delete, or modify segment message. 

• [step 2202] The S-DAI receives the request. 

• [step 2203] It then calls the appropriate function in the Classic module, 
which uses Classic to determine all of the segment/partition changes the 
request induces. 

• [step 2004] These changes (or an appropriate error condition) are returned; 
if there is an error, this is passed back to the Client with no changes to the 
Metadata™ tables. 

• [step 2205] If there is no error, all changes are passed to the Metadata™ 
tables. 

• [step 2206] Again, assuming no errors, an acknowledge message is sent to 
the Client. 

• [step 2207] If the knowledge base is changed, the appropriate knowledge 
base file is updated. 

The user's segment hierarchy is kept persistent in a knowledge base files on 
the Server disk. This is because it would be too time-consuming to re-create it each and 
every time from the Metadata™ tables. There is one knowledge base file for each 
dimension and each user. Each file reside in some area on the Server disk and be named 
"dimension. user". 
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The user 1405 adds a new segment by selecting an existing segment (perhaps 
the top level segment) and then selecting a sequence of attributes and restrictions. This 
sequence defines a sequence of partitions and attributes. Consider the set of attributes and 
restrictions of: {age > 65, income > 100K}. This segment might be called "Wealthy 
Seniors". 
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This would give rise to the following sequence, assuming the segment was defined at the 
top level: 

All Customers 

[By-Age] < = partition named by its attribute 

Age > 65 < = automatically named intermediate 

egment 

[By-Income] 

Wealthy Seniors < = user-defined and named segment 

The order of attributes is very important. That is, the final segment, 
"Wealthy Seniors", could also have been defined by Income and then by Age, with the 
same resulting final segment. However, the automatically created intermediate segment, 
and the two automatically created partitions, would be different. (In this case, the first 
partition would be "By-Income", the intermediate segment would be u Income> 100 n , and 
the second partition would be "By-Age"). 

The following guidelines are supported for the creating of new segments: 

1. The final user-named segment is created 

2. "Supporting" partitions and segments are automatically created and named 
but only in the attribut e order p en erated bv the user 1405 

3. If the final segment is a child of any existing partition it "appears there" as 
well. 

4. If the final segment differs by a single attribute from an existing segment, 
the one intermediate supporting partition will be created. 

5. If any segments are classified under the new segment and differ by just one 
attribute, the appropriate partition is created. 
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To illustrate guideline 4 above, let us assume the Customer hierarchy looks 

like this: 

All Customers 
[By-Income] 

Moderate-Income 
High-Income 



The user defines "Wealthy Seniors" as above. The hierarchy should now 

look like this: 

All Customers 
[By-Age] 
Age > 65 

[By -Income] 

Wealthy Seniors 

[By-Income] 

Moderate-Income 
High-Income 
[By-Age] 

Wealthy Seniors < = segment and partition automatically 
added 

Likewise, when the user 1405 adds a new segment, if there is an existing 
segment that belongs under that segment, differing by a single attribute, the existing 
segment will be put under the new segment and the new partition will be created. 

The segment/partition hierarchy is somewhat of a strange beast. It is rooted 
at the "top-level segment" for that dimension, which is a segment with no attribute 
restrictions (this is why it represents "ALLOT, where X is the dimension, like Customer 
or Product). Each segment has a number of child partitions. Each partition represents a 
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segmentation by a single attribute and has a number of child segments. A segment can 
belong to several partitions. A partition has only one parent segment. 

The user 1405 creates a new segment by selecting a starting or parent 
segment, choosing a name for the final segment, and then entering a set of attributes and 
restrictions in the user interface. For each attribute restriction (in the order the user chose) 
a segment will be created and added to the segment/partition hierarchy. When a segment is 
added, partitions may need to be created both above and below the new segment. 

Fig. 23 shows the addition of a segment (without loss of generality, one that 
differs from its parent by one attribute restriction). First, the new segment must be "fit" 
with a partition underneath its specified parent. If the new segment fits in an existing 
partition or partitions, it is added to those partitions (reference numeral 2301). If not, a 
new partition is created, (reference numeral 2302). As with all new partitions, other 
segments may fit and be added. For all other parents of the new segment (Classic will tell 
us all parents), we first make sure the new segment and parent differ by only 1 attribute. If 
so, as is true of the parent at reference numeral 2303, we again add to existing partitions 
(reference numeral 2304) or create a new one. (The Parent at reference numeral 2305 
differs by more than one attribute. This means we don't know the order of the intervening 
segments, so we leave it alone.) Finally, any children segments of the new segment (like 
reference numeral 2306) (Classic will tell us the children of a segment) are fitted with new 
or existing partitions, like reference numeral 2307. 

The following is a very brief sketch of the algorithm for adding a new 
segment to a user's hierarchy. When Classic I4AA is used, this is indicated by 
underlining . 

INPUT: a parent segment and a new segment (NEW). The new segment 
consists of a single added attribute restriction. When the user 1405 inputs more than one 
attribute restriction, this basic algorithm is called several times, with names generated for 
the intermediate segments. 

greate a temporary Classic segment for NEW 
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If NEW is identical to an existing segment return 
/* for each parent: 

check that the level difference is one 

either add the segment to an existing partition or 

create a partition, add the segment, then add additional segments 

*/ 

net the parent segments of NEW 
for each Parent { 

if the level difference = =7 { 
fits_flag = FALSE; 

for each child partition of this segment { 
If the segment fits in this partition ( 
fitsjlag = TRUE; 
add the segment to the partition 

} 

} 

if (!f1ts_f]ag) { 

create a new partition under the parent 
add the segment to the partition 
for all other children of the current parent { 
if the child fits, (his new partition 
add it to the partition 

} 

} 

} 

} 

/* Now that the segment has been added to all its parents: 
For all children of the new segment: 
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check to see the level difference is 1 

either add it to an existing partition or 
create one 

*/ 

Get the children of the segment NEW 
For each child { 

if the level difference. = = / { 

for each child partition of NEW { 
if child fits with partition { 
add it to the partition 
fits_flag - TRUE 

} 

else { 

create a new partition under NEW 
add the child to it 

} 

} 

} 



Deleting a segment can be surprisingly tricky. That is because various 
changes in the hierarchy can occur when a single segment is deleted. By design, we require 
that children of a segment to be deleted are themselves deleted if no other partitions refer 
to them. 

With reference to Fig. 24: 

FOR ALL PARENT PARTITIONS 

[2401] remove the parent/segment link 

[2402] if no other segment, delete the partition 

FOR ALL CHILDREN OF THE PARENT SEGMENT 
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[2404] see if they w fif the partition now 
FOR ALL PARENT PARTITIONS 

[2405] see if they are redundant and can be "collapsed* 
FOR ALL CHILD PARTITIONS 

[2406] remove the segmenl/parttion Jink 
[2407] delete the partition 
FOR ALL CHILD SEGMENTS 

[2408] delete the child segment link 
[2409] if they have no parent partition, DELETE 
[2410] DELETE THE SEGMENT 

Mention was previously made of an "other" segment (referred to herein as 
"OS") that represents those entities not captured by the explicit segments in the final 
partition. For example, in a hierarchy that looks like this: 
All Customers 
[By-Age] 

Ago 65 

[By-Income] 
Wealthy Seniors 

the OS under the partition "By-Income" would represent people older than 65 but whose 
income does not make them wealthy. 

The OS will not be represented explicitly in the hierarchy. This is because 
its definition will change depending on what segments exist. For example, if the user added 
a segment called "Middle class seniors", the definition of the OS would change. Rather, 
the OS is implicit and its attribute restrictions can be computed by taking the restrictions of 
its sibling segments and negating them. 

The Classic knowledge base must be initialized from the persistent 
Metadata™ tables 25, either when a user 1405 first logs in or when a segment update 
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request is received. Each dimension and its respective segments and partitions can be 
treated as a separate knowledge base. The initialization can be performed in two ways: (1) 
by making direct calls to Classic I4AA, or (2) by creating an ASCII flat Hie that Classic 
14AA can read. The former is probably more efficient, while the latter may have 
advantages for debugging and retraction on error. 

The general steps to create a Classic kno wedge base are as follows, with 
reference to the tabic previously defined; 

• For each Dimension, read from the Dimension Definition table 
=> define a dimension_fiIler individual for that Dimension 
=> For each numeric or string attribute 

0 define the attribute role 
=> For each enumerated attribute 

0 define the attribute role 

0 define the primitive "filler" 

0 for each enumerated attribute value 
* define the value individual 
=> For each segment definition 

0 get all the attribute restrictions 

0 define the segment 

0 define the segment individual 
=> For all partitions 

0 create a partition individual 
=> For all Segment to Child Partition mapping 

0 create the mapping by adding the partition individual to the 
segment individual 
=> For all Partition to Child Segment mapping 

0 create the mapping by adding the segment individual to the 
partition individual 
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The modification of Metadata™, including the addition, deletion, and editing 
(changing) of Metadata™ by both MDT Business-level users and the MDT Administrator 
(or Analyst level user), will now be described. 

To modify Metadata™ means to change it. In one embodiment, there are 
three kinds of change supported by the Serial DAI 14A and the Client interface: addition, 
deletion, and editing. The kinds of Metadata™ involved typically include segments, 
composite measures, and measure relationships. There are two kinds of users 1405 who 
modify Metadata™: normal (or "level" users), and the MDT Administrator or Analyst 
Level user, both refered to in this document as the MDTA. The MDT A can usually, but 
not always, be thought of as another user editing public Metadata™. We are generally not 
concerned here with the MDTA changing other kinds of MDT Metadata™ like the mapping 
and join information. The table below summarizes these combinations: 



Subject 


Action 


Object 


User 


Add 


Segments 


MDTA 


Delete 


Composite Measures 




Edit 


Measure 






Relationships 


MDTA 


Add 


Dimensions 




Delete 


Attributes 






Basic Measures 



Modification of Metadata™ is done through the Client interface, including 
the segment builder, measure builder, measure relationship builder, and some setup 
screens. The general flow of control is from the Client 12 lo the Serial DAI (S-D AI) 14A, 
to the Classic component 14AA if segments are involved, and then to the Metadata™ 
tables 25, Various warnings and errors may be presented to the user 1405, as appropriate. 

Modification of Metadata™ gets tricky for two reasons. First, their exist 
dependencies between Metadata™, for example, between segments and composite measures 
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that refer to a segment, or dependencies between "public" Metadata™ managed by the 
MDTA and various user's private Metadata™ . Second, defined analysts, either scheduled 
or unscheduled, may refer to Metadata™ that has been modified. Several important issues 
must be addressed, for example: 

1. What happens when an analyst refers to missing Metadata™ , i.e., 
Metadata™ that has been deleted? 

2. What happens when Metadata™ is deleted and other Metadata™ refers to it? 

3. When the MDTA changes public segments, how are the user's segment 
hierarchies updated? 

4. What happens when the MDTA deletes a dimension, attribute, or basic 
measure? 

One can imagine two extreme approaches along a spectrum: one, do no 
checking whatsoever (a "user beware" approach), two, try to capture and prevent all 
potential problems. In a preferred embodiment, the present invention may be designed to 
be closer to the u user beware" side of the spectrum, although any other suitable design 
may be implemented. Given this, it is desirable to give the user 1405 warnings and 
information when available and to not do anything that surprises the user 1405 without 
warning and, if possible, confirmation. 

The Concurrent DAI (CDAI) 14B (Fig. 19) is the MDT subsystem that 
generates InfoFrames™. Its input is an InfoFrame™ Request from the Client 12 or 
Scheduler subsystems 18 and its output is an InfoFrame™ containing an external HTML 
text report contained in a file in the User Return Area. The working of the CDAI 
subsystem 14B, including how it is structured and the format of the resulting reports, are 
provided below. 

The CDAI 14B may be a UNIX™ or NT process executing on the UOTX™ 
or NT Server platform. It is invoked by a Dispatcher component with the command line 
such as: 



113 



(241) 10-207751 



mdtqueryengine [-c <config>] f-e <errlog>] 
where the config name and the errlog name are optional Configuration file and Error Log 
names respectively, inherited by the Dispatcher from the Master's command line when the 
Master invokes it. 

Certain features of the CDAPs J4B function may be determined by the 
value of attributes defined in a Configuration file. These attribute values specify the 
thresholds for In teres lingness Heuristics, Localization Parameters and etc. 

The CDAI 14B will generate an InfoFramc™ for the User and Error Logs 
for the MDT Administrator in the local text. The User's local (and language) may not be 
the same as the Administrator's however. For this reason, the CDAI 14B may reference 
two Message Catalogs to collect localized text. The Native catalog will be used as a source 
for localized text for InfoFrames™. The Error catalog will be used as a source of localized 
text for the Error Log. 

The text of the generated InfoFrame™ will be localizable. The localized 
names of Measures, Segments and Time Periods will be provided by the Client 12 or 
extracted from the Metadata. Other text will be kept as parameterized strings in an MDT 
Message Catalog. This is known as the Native catalog. The CDAI 14B will compute the 
name of the Native catalog from the value of the MsgCatalogPath attribute contained in the 
configuration file and the ISO language name provided by the client. A separate catalog 
must preferrably be kept to generate Error Logs in the MDT Administrators language. 

The CDAI 34B will accept one mdtJnfoFrameRequest object in an 
RUN_ANALYST_REQUEST message. The Request may contain an InfoFrame 
Definition (mdtJnfoFrameDefinition), describing the InfoFrame™ to be generated. It may 
specify the type of the InfoFrame™, the Segment(s) to be reported over, the Measure(s) to 
be reported on and the Time Period(s) to report for. In one embodiment, there are five 
types of Reports. These are: 

• Summarization . The basic analysis of a target measure over a target segment 



114 



(24 2) 



1 0-2077 



• Chanee Analyst - Summarization of the difference of a target measure over two 
separate time periods and over a target segment 

• Measure Comparison - Summarization of the difference between two measures 
over a target segment 

• Segment Comparison - Comparison of the same measure over two separate 
target segments 

• Trend Analysis. - Report of trends over time in the target measure and related 
measures over the target segment and related segments 

The Request may contain an InfoFrame™ Trigger (mdtJnfoFrameTrigger). 
TTie Trigger defines a test for some condition in the data warehouse 24 and an Alert flag 
and may contain a "nested" InfoFrame™ Request. If the Request contains a Trigger, the 
CDAI 14B must only Implement the InfoFrame™ Definition if the condition is true. If the 
condition is true, the CDAI 14B must also, if the Alert flag is true, generate an Alert and, 
if the Trigger contains an nested Request, execute the nested Request. 

In general, the CDAI's 14B output will be an InfoFrame™ object containing 
a localized, extended HTML Report (see Fig. 12). The InfoFrame™ will be written into a 
file in the User Return Area (defined below). 

The User Return Area is a directory whose path is given by the 
UserReturnAreaPath parameter fo the configuration file. On successful completion of the 
InfoFrame™, the report will be named INF. < UID> . <UNQ> where UID is a User ID 
and UNQ is some siring which guarantees that this file name will be unique from all other 
file names generated for this User.. 

The Unique identifier will be generated by the Dispatcher when it launches 
the CD A3 14B and will make it available to the CDAI 14B with the InfoFrame™ request. 
As each Report requires a unique name, a CDAI 14B instance can only generate one 
Report. Where an InfoFrame™ Request specifies more than one report, when a triggered 
request requires an Alert Report and 'other' Reports as well as 'the 1 Report, the CDAI 14B 
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accepting the request will need to dispatch new CDAI's 14B to deal with this mulutide of 
Reports. 

These extensions will be interpreted by the Client viewer. The Report 
will contain either an InfoFrame™ Report, an Alert Report or an Error Report. An 
InfoFrame™ Report will be generated when the CDAI 14B successfully completes an 
InfForame definition. It will be generated by the ifgn_Report class. 

An Alert Report will be generated when an InfoFrame™ Request has a 
trigger and that trigger evaluates to true and the Alert flag is set. Jt will be generated by the 
ifgn_AlertFrame class. 

An Error Frame will be generated when the CDAI 14B is unable to evaluate 
a trigger or an InfoFrame™ definition and lives to tell about it. It will be generated by the 
ifgn_ErrorFrame class. 

The content of the InfoFrame™ Report (see Fig. 12) is highly variable, 
depending not only on the type of analysis required but on the values of the measures 
encountered. The Report may be organized in a variety of ways, such as a heading, four 
bulleted paragraphs, a table, etc. For example: 

Heading - Quotes the Analyst Description provided by the User when the Analyst is 
defined and names the Segments, Measures and Time Periods analysed and, if the 
Analyst had a trigger, the trigger terms and the time at which the trigger condition was 
satisfied. 

• Target Segments Report - A bulleted paragraph which contains; 

Target Segments - Text highlighting the results for the measure(s) over the 
segment(s) and time period(s) directly specified in the analyst definition. 
Additional measures are not reported in this section. 
Parent Contribution - A bulleted paragraph highlighting any significant 
contribution made by the target segment(s) to its parent segment. This section 
is not included when the target segment(s) is a lop level segment or if the target 
measure(s) contains a reference to a parent segment. 
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Sibling Comparison - A bulleted paragraph offering interesting comparisons of 
the target segments)' value to the values of its sibling segments. This section is 
not included when the target segment(s) is a top level segment. 
Sibling Graphs - A bar or pie chart showing the values of the sibling segments 
or a Line graph showing trends. This graph is not produced if there are Drill 
Down segments. 

• Pril l Pcwn - A bulleted paragraph highlighting interesting relationships between 
the values of child segments in the drill down partition(s) to the value, for the 
target segment. Drill Down partitions may be specified by the user in the 
analyst definition. If the user does not specify any drill down partitions, MDT 
automatically chooses one or more interesting partitions. See the section below 
on choosing drill down partitions to learn how they are automatically chosen. 
This section is not included when no child partition exists and no unrestricted 
attributes exist to create or if no existing or created partition is interesting. 
Drill Down Graph - A bar or pie chart showing the values for the Drill Down 
Sements or a Line chart showing trends. This graph is not produced if there are 
no interesting Drill Down segments. 

• Formula Decomposition - A bulleted paragraph highlighting interesting 
contributions to the composite measure of its component measures. This section 
is included only when the target measure is a composite measure. 

• Measure Relationships - A bulleted paragraph describing possible causes for the 
difference between two values of the target measure (or the difference between 
the target and comparison measures for the Measure Comparison Analysis). The 
Summarization Anaiyis will not contain a Measure Relations paragraph. 

Table - A table showing all the measure values reported during the analysis 
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Segments other than the Parent, Target or Comparison segment may be 
marked as hyperlinks (see again, e.g., Fig. 12). The underlying HREF will contain the 
information required to substitute this segment as the target segment for a new analyst of 
the same type, for. the same measure, comparisons and periods. 

The Alert Report is much more straight forward. It's most interesting 
characteristic is the hyperlink to the Analyst Name. When the InfoFrame™ Request was 
defined, an AnaJsyst may have been defined to optionally gather more information on the 
event. By selecting the hyperlink, the User can launch this Analyst. The text of the Alert 
frame may look like: 



Alert: < Analyse Name > 

< Target Segment > 

< Additional Segment 1 > 

< Additional Segment n > 

<Base Time Period Description> 

Alert was triggered at <time alert iriggered> 

Click he re to run < Analyst Name> now. 

Trigger is: < Measure Name > [ < Operator> < Measure Name > ] , 
< Measure Name> [< Operator > < Measure Name>] t 

< Measure Name> [< Operator > < Measure Name>] 



An Error Report may be simpler still. It is meant to communicate exactly 
one statement to the User 1405, a description of the error encountered. The format may be: 

Error: < Analyst Name > 

An Error Occurred at <timc error occurred > 
< Error Text> 
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The CDAI 14B may report errors to a server error log. The texts of the 
error messages are maintained in the error message catalog as parameterized, localizable 
strings. 

4 - DSM Subs ystem 16 and Scheduler Subsystem 18 

The data and schema manipulation subsystem 16 and scheduler subsystem 18 
are described in further detail below. 

The MDT Server 32 may implement two classes of Requests for the User 

1405. 

• Interactive Requests; Metadata™ Fetch, Metadata™ Update, InfoFrame™ 
Scheduling, InfoFrame™ Status and etc. The Server will implement one 
Interactive Request at a time for each Client. That we handle one Interactive 
Request at a time is almost as interesting as that they are interactive so we 
will also call these Serial Requests. 

• Batch Requests; Trigger Requests and InfoFrame™ Generation. The Server 
must be able to implement multiple Batch Requests at a time. That we must 
handle multiple Batch Requests at a time is almost as interesting as that they 
are batch so we will also call these Concurrent Requests. 

Each Concurrent Request will cause one or more queries against the 
Database. The ODBC standard supports asynchronous queries against the database but 
many implementations of ODBC do not. In these implementations, each Concurrent 
Request will require its own process. Because putting each Request in its own process 
allows us to work with many more ODBC implementations and passes responsibility for 
managing the memory and data structures for multiple Requests to the operating system, 
each Concurrent Request will be get its own process. This process will be the Concurrent 
instance. 
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If Serial Requests and returning results are made to be asynchronous events, 
a single Server instance might be able to handle all of the Server's Serial Requests. But 
implementing asynchronously, while not overly difficult, is rather pointless when each 
Client 12 can simply be handed a new Server instance. Each Client 12 is therefore assigned 
a Serial instance to handle its Interactive Requests. 

Its important to note that Windows NT ™ implements threads, and future 
revisions of the UNIX ™ operating system should as well. Threads provide an opportunity 
to pass responsibility for handling asynchronous events to the operating system while still 
managing memory in a single process. 

Also, for purposes of the present invention description, it will be assumed 
that the Serial and Concurrent instances will be implemented by unique executables, each 
implementing a subset of complete Server functionality appropriate to its Requests. 

With reference to Fig. 25, the Server 32 may be implemented as a collection 
of cooperating processes. There will be five classes of processes, as described below: 

• The Master process 25 1 1, responsible for accepting Client connections with 
the Server and assign the Client 12 a Serial instance. 

• The Serial instance 2512, responsible for executing all of this Clients Serial 
Requests. These will be Metadata™ Fetches and Updates, InfoFrame™ 
Scheduling Requests and etc. The Serial instance will queue Scheduled 
InfoFrame™ Requests in the Scheduler's Queue. The Serial instance will 
also get the Client's InfoFrame™ Generation Requests, a Concurrent 
Request, but it will pass this on the Dispatcher. 

• The Dispatcher process 2513, responsible for assigning a Concurrent 
instance to each Concurrent Request passed to it by the Serial instance or the 
Scheduler and for reporting the state of pending and executing Concurrent 
Requests. 

• The Concurrent instance 2514, responsible for executing a single 
Concurrent Request. 
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• The Scheduler processes 18, responsible for passing InfoFrame™ Requests 
to the Dispatcher at the scheduled time. 

Create relationships are indicated with white pointers 2501 from parent to 
child. Request relationships are indicated with black arrows 2502 from sender to recipient. 

A process of the Server will share several resources in common to present a 
single state to the client. These are the Metadata™, the Scheduler Queue and the Return 
Area. 

When a User 1405 makes a change to the User's Metadata™, that change 
must be visible to all of the User's subsequent InfoFrame™ Requests. When that User 1405 
is the MDTA (Administrator) and the MDTA specifies changes to global Metadata™, these 
changes must be visible to all subsequent Requests. 

MDT's Metadata™ will be stored on the Customer's Data Warehouse 24. 
Accesses to this Metadata™ will be managed by the DSM 16. In order to optimize accesses 
to the Metadata™, the DSM 16 will implement a shared memory, write through cache of 
the MDT tables. 

Each User 1405 will use only a subset of Metadata™, and for practical 
reasons that data will be re-organized from flat tables of the database into an application 
specific structure. Each of the User's Serial and Concurrent instances 2512 , 2514 will need 
to keep a copy of this subset. This image will be constructed and maintained by the DAI 
14. 

When a User 1405 modifies a Metadata™ item, the DAI 14 will effect the 
change to the local image and will command the DSM 16 it update the data warehouse 24. 
The DSM 16 will write this change into the shared memory cache and through the cache to 
the warehouse 24 . 

The relationships and operations on Metadata™ are illustrated schematically 
in Fig. 26. The light arrows 2601 represent attachments to the shared memory Metadata™ 
Cache 2610. The bold arrows 2602 represent the path of Metadata™. 
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The present MDT invention will maintain a single Scheduler Queue which 
will list all of the InfoFrame™ Requests scheduled to execute at some future time or to 
execute at regular intervals. 

When the User 1405 schedules an InfoFrame™ Request through the Client 
12, the Schedule Request will be passed through the Serial instance 2512 to the Scheduler 
18. The Scheduler 18 will accept the Request and will place the Request in the Schedule 
Queue. When the User 1405 deletes a Scheduled Request the Scheduler 18 will delete the 
Request from the Scheduler Queue. The DAI 14 will also accept a User's Schedule Status 
Requests. It will satisfy them by inspection of the Scheduler Queue. 

At regular intervals, the Scheduler 18 will inspect the Scheduler Queue, will 
identify Requests that have come due and will pass them to the Dispatcher 2513. The 
Scheduler 18 will then remove non-recurring Requests from the Scheduler Queue. 

The Dispatcher 2513 will create a Concurrent instance 2514 to execute the 
Requests. A Concurrent instance 2514 is a process and expect processes should be a limited 
resource which must be managed by the Dispatcher 2513. Thus, an InfoFrame™ Request 
passed to the Dispatcher 2513 may exist in one of two states: (1) pending (waiting for a 
process) and (2) Executing. The Dispatcher 25 13 will keep a list of Pending and Executing 
Requests. When the User 1405 makes an InfoFrame™ Status Request, the Client 12 will 
pass it to the Serial instance 2512 and the DAI 14 will implement it. It will need to collect 
the list of the User's Request status from the Dispatcher 2513 to complete the Status 
Request. 

The relationships and operations on the Scheduler Queue 2710 are illustrated 
schematically in Fig. 27. The path of the InfoFrame™ Request is represented by the black 
arrows 2701. Status Information regarding scheduled Requests and Pending or Executing 
Requests, which must be collected by the Serial instance in response to the Client's status 
Requests, is represented by White arrows 2702. - 
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Completed InfoFrames™ will be parked in the Return Area between the time 
they are completed and the time the Client 12 calls to collect them. The Return Area is 
simply a directory on the file system. It will contain a sub-directory for each user 1405. 

When the Concurrent instance 2514 completes an InfoFrame™ Request it 
will copy the InfoFrame™ into the User's sub-directory of the Return Area. Recurrent 
Requests may leave many InfoFrames™ in the Return Area. The Concurrent instance 2514 
must generate unique names for each Report. 

The Client 12 will occasionally pass InfoFrame™ Status Requests to the 
Serial instance 2512. The DAI 14 will implement the Request. The DAI 14 will need to 
inspect the User's sub-directory of the Return Area to identify the InfoFrames™ that have 
been completed. The DAI 14 might 'decode' the file names to produce Analyst names and 
execution dates to report to the Client 12. 

The Client 12 will also occasionally pass InfoFrame™ Upload Requests to 
the Serial instance 2512. The DAI 14 will implement the Request. The DAI 14 will collect 
the InfoFrame™ from the User's sub-directory of the Return Area. It will pass the 
InfoFrame™ to the Client 12 and will remove the image from the Return Area when the 
Client 12 acknowledges receipt. 

The relationships and operations on the Return Area 2810 are illustrated 
schematically in Fig. 28. The flow of the completed InfoFrame™ is represented by the 
black arrow 2801. The movement of status required by the Serial instance 2512 to satisfy a 
Client Status Request is represented by the white arrow 2802. 

1. DSM Subsystem 16 

The DSM Subsystem 16 is described in further detail below. 

The SQL Generator receives a Dimensional Query from the InfoFrame™ 
Generator, generates the necessary database queries, and returns the results to the 
InfoFrame™ Generator. The interface to the database is through ODBC, which takes 
queries in the form of SQL strings. 
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The SQL Generator must query the database 24 to evaluate each 
Measure/Segment pair. The Measures may be from the dai_MeasureList. In the first form 
of QueryDatabaseO, the segments are the child segments of the targetPartition; in the 
second form, each Measure is evaluated only for the implied target segment. Each of the 
measures may be a Composite Measure, which may require multiple queries to evaluate the 
Measures that make up the Composite Measure, 

Standard SQL programming techniques may be used to implement the DSM 

Subsystem 16. 

2. Scheduler Subsystem 18 

The scheduler subsystem 18 is described in further detail below. 

The scheduler subsystem 18 is responsible for submitting Analysts with 
schedules and/or triggers to be run. It is also responsible for maintaining lists of scheduled 
and/or triggered Analysts; deleting, modifying and adding to those lists. 

In this section, an Analyst which has a schedule, a trigger, or a schedule and 
a trigger will be referred to as a 'scheduled* Analyst unless there is a difference in the way 
the three types of Analysts behave. 

When an InfoFrame™ request is received by the S-DAI subsystem 14A, it 
will be passed to the Scheduler subsystem 18 if it is associated with a scheduled Analyst. 
The Scheduler 18 will determine the proper time period in which to dispatch the Analyst. 
When it is scheduled to run, a request will be passed to the dispatcher 2513 as in the same 
manner thai the S-DAI subsystem 14A passes non-scheduled requests. 

Fig. 29 illustrates this process in further detail. 

From the S-DAI 14A, the Scheduler 18 will receive scheduled InfoFrame™ 
requests, delete and disable user requests, delete scheduled Analyst requests. To uniquely 
identify requests, the S-DAI 14A must provide an Analyst id (contained in ihe InfoFrame™ 
request object) and a user id. 
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When a scheduled InfoFrame™ request is received, the Analyst is placed on 
the Trigger List 2901 if the Analyst has a trigger, or the Schedule List 2902 if it has either 
a schedule or a schedule and a trigger. The difference between a triggered Analyst and a 
scheduled, triggered Analyst is that the former is mn at each trigger period while the latter 
is run only when scheduled. 

The Scheduler 18 has two execution time periods, one for triggered requests 
and one for scheduled requests. The two time periods are configurable on each MDT 
server 32 and may be changed by the MDT Administrator. 

When the trigger time period occurs, the Scheduler 18 traverses its list 2901 
of triggered events. For those scheduled to run during that time slice and whose user 
account is enabled, a copy of the InfoFrame™ request without the trigger is passed to the 
Dispatcher 25 13. An analogous process is followed for the schedule time period and 
schedule list 2902. 

If a user 1405 is deleted, the Scheduler 18 will remove any Analysts from 
the lists which are owned by the deleted user. If a user 1405 is disabled, any Analysts on 
the lists will not run until the user 1405 is once again enabled. If an Analyst is modified, 
the user 1405 must explicitly remove any associated scheduled requests or they will 
continue to run with the old Analyst definition. 
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Fig. 1 is a block diagram of the system of the present invention; 
Fig. 2 is a block diagram of a client subsystem within the system of Fig. i ; 
Fig. 3 is a block diagram of a data abstraction intelligence subsystem within the 
system of Fig. 1; - 

Fig. 4 is a block diagram of a data and schema manipulation subsystem within the 
system of Fig. 1; 

Fig. 5 is a block diagram of a scheduler subsystem within the system of Fig. 1; 
Figs. 6-12 are views of a tool for creating reports which employs a graphic user 
interface; 

Fig. 13 is a flow diagram illustrating how Metadata™ is created. 

Fig. 14 is another block diagram of a client subsystem within the system of Fig. I. 

Fig. 15 is yet another block diagram of a client subsystem within the system of Fig. 

I. 

Fig. 16 is a database heirarchy that may be created according to the teachings of the 
present invention. 

Fig. .17 is another heirarchy that may be created according to the teachings of the 
present invention. 

Fig. 18 is yet another heirarchy that may be created according to the teachings of 
the present invention. 

Fig. 19 is a general, high-level data flow between the DAI and the other subsystems 
and components of the system of the present invention. 

Fig. 20 is an architecture of a Serial DAI subsystem of Fig. 1. 

Fig. 21 is a flow diagram for the Serial DAI system of Fig. 1. 

Fig. 22 is another flow diagram for the Serial DAI system of Fig. 1. 

Fig. 23 is a depiction of the addition of a database segment in the system of the 
present invention. 

Fig. 24 is a depiction of the deletion of a database segment in the system of the 
present invention. 

Fig. 25 is a description of the processes performed by the server of Fig. 1. 
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Fig. 26 is a diagram showing the relationships and operations with respect to 
Metadata™. 

Fig. 27 is a diagram showing the relationships and operations with respect to the 
scheduler queue. 

Fig. 28 is a diagram showing the relationships and operations with respect to the 
return area. 

Fig. 29 is a diagram depicting the requests performed by an analyst. 
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FIG. 4 
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A system for performing intelligent analysis, segmentation and partition of a 
database based upon attributes associated with the data in the database axe provided. A 
report may be generated which allows a user to make decisions, without requiring the user 
to understand or interpret data itself. A database computer includes a database containing 
the data. The data includes a collection of information about an enterprise of the user. A 
server computer is coupled to the database computer and executes a database management 
program. A client computer is coupled to the server and executes an application program 
The application program allows a user to define predetermined data types, to define 
relationships between the data types, to define parameters for the report, to define a 
method of analysis for the report, and to create the report. The report summarizes the data 
in terms of the data types, the data relationships and the method of analysis. 
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